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Abstracto 


Este documento especifica un proceso para cifrar datos y representar el resultado en XML. Los datos pueden estar en una variedad de 
formatos, incluidos flujos de octetos y otros datos no estructurados, o formatos de datos estructurados como documentos XML, un 
elemento XML o contenido de un elemento XML. El resultado del cifrado de datos es un elemento de cifrado XML que contiene o hace 
referencia a los datos cifrados. 


Estado de este documento 


Esta sección describe el estado de este documento en el momento de su publicación. Otros documentos pueden reemplazar este documento. 


muestra cuatro implementaciones con al menos dos implementaciones interoperables en cada característica. 


Consulte el informe de implementación de la versión 1.1 de esta especificación para obtener detalles adicionales sobre el estado de 
implementación de las funciones agregadas en esta revisión. 


Los cambios que afectan la conformidad con respecto a la Recomendación anterior afectan principalmente al conjunto de algoritmos 
criptográficos obligatorios para implementar, agregando el Acuerdo de Clave Diffie-Hellman de Curva Elíptica, haciendo obligatorio AES-128 
GCM, cambiando RSA v1.5 a opcional, agregando AES192-GCM opcional y agregando variantes opcionales del algoritmo RSA-OEAP. 
También se han agregado importantes consideraciones de seguridad. Un resumen detallado de los cambios está disponible en [ XMLENC- 
CORE1-CHGS ]. Los cambios también se describen en un documento de diferencias que muestra los cambios desde la Recomendación 
original , así como en un documento de diferencias que muestra los cambios desde el borrador de PR anterior . 


Este documento fue publicado por el Grupo de Trabajo de Seguridad XML como recomendación. Si desea hacer comentarios sobre este 
documento, envielos a public-xmlsec@w3.org ( suscríbase , archivos ). Todos los comentarios son bienvenidos. 


lista pública de cualquier divulgación de patentes realizada en relación con los productos del grupo; esa página también incluye 
instrucciones para divulgar una patente. Una persona que tenga conocimiento real de una patente que cree que contiene Reivindicaciones 
Esenciales debe revelar la información de acuerdo con la sección 6 de la Política de Patentes del W3C . 


También está disponible información adicional relacionada con el estado de los derechos de propiedad intelectual de XML Encryption 1.1 . 
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1. Introducción 


Este documento especifica un proceso para cifrar datos y representar el resultado en XML. Los datos pueden ser datos arbitrarios (incluido 
un documento XML), un elemento XML o contenido de un elemento XML. El resultado del cifrado de datos es un elemento de cifrado XML 
EncryptedDataque contiene (a través de uno de sus contenidos secundarios) o identifica (a través de una referencia URI) los datos cifrados. 


Al cifrar un elemento XML o el contenido del elemento, el EncryptedDataelemento reemplaza el elemento o el contenido (respectivamente) 
en la versión cifrada del documento XML. 


Al cifrar datos arbitrarios (incluidos documentos XML completos), el EncryptedDataelemento puede convertirse en la raíz de un nuevo 
documento XML o convertirse en un elemento secundario en un documento XML elegido por la aplicación. 


1.1 Convenciones editoriales y de conformidad 


Esta especificación utiliza esquemas XML [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] para describir el modelo de contenido. La gramática 
normativa completa está definida por el esquema XSD y el texto normativo de esta especificación. El archivo de esquema XSD 
independiente tiene autoridad en caso de que exista algún desacuerdo entre él y las partes del esquema XSD. 


Las palabras clave " DEBE "," NO DEBE ”, " REQUERIDO ", " DEBE”, " NO DEBE", " DEBE "," NO DEBE ", " RECOMENDADO ", 
esta especificación son debe interpretarse como se describe en [ RFC2119 ]: 


PUEDE " y " OPCIONAL " en 


" Sólo DEBEN utilizarse cuando sea realmente necesario para la interoperación o para limitar comportamientos que puedan 
causar daño (por ejemplo, limitar las retransmisiones)" 


En consecuencia, utilizamos estas palabras clave en mayúscula para especificar sin ambigiiedades los requisitos sobre las características 
y el comportamiento del protocolo y la aplicación que afectan la interoperabilidad y la seguridad de las implementaciones. Estas palabras 
clave no se utilizan (en mayúscula) para describir la gramática XML; Las definiciones de esquema describen inequívocamente dichos 
requisitos y deseamos reservar la prominencia de estos términos para las descripciones en lenguaje natural de protocolos y 
características. Por ejemplo, un atributo XML podría describirse como "opcional". El cumplimiento de la especificación del espacio de 
nombres XML [ XML-NAMES ] se describe como " REQUIRED ". 


1.2 Filosofía del diseño 


La filosofía de diseño y los requisitos de esta especificación (incluidas las limitaciones relacionadas con la validez de la instancia) se 
abordan en los Requisitos de cifrado XML originales [ XML-ENCRYPTION-REQ ] y el documento Requisitos de seguridad XML 1.1 [ 
XMLSEC11-REQS ]. 


1.3 Versiones, espacios de nombres, URI e identificadores 


Esta especificación utiliza espacios de nombres XML y utiliza identificadores uniformes de recursos [ URI ] para identificar recursos, 
algoritmos y semántica. 


Las implementaciones de esta especificación DEBEN utilizar los siguientes URI de espacio de nombres XML: 


URI prefijo de espacio de nombres entidad interna XML 
http: //www.w3.org/2001/04/xmlenc# espacio de nombres predeterminado , xenc: <! ENTITY xenc "http: //ww.w3.org/2001/04/xmlenc+"> 
http: //www.w3.org/2009/xmlenc11# xenc11: <!ENTITY xenc11 "http://ww.w3.org/2009/xmlenc11+t"> 


El espacio de nombres http: //www.w3.org/2001/04/xmlenc# ( xenc:) se introdujo en la versión 1.0 de esta especificación. La versión actual 
no acuña ningún elemento nuevo ni identificador de algoritmo en ese espacio de nombres; en su lugar, se utiliza el espacio de nombres 
http: //www.w3 .org/2009/xmlenc11+( ).xenc11: 


No se prevé ningún número de versión explícito en esta sintaxis. Si una versión futura de esta especificación requiere una versión explícita 
del formato del documento, se utilizará un espacio de nombres diferente. 


Además, esta especificación utiliza elementos e identificadores de algoritmos de los espacios de nombres de firma XML [ XMLDSIG-CORE1 


Į: 


URI prefijo de espacio de nombres entidad interna XML 


espacio de nombres predeterminado , <!ENTITY dsig 


http: //ww.w3.org/2000/09/xmldsig# 
P 8 g ds:,dsig: "http: //www.w3.org/2000/09/xmldsig#"> 


URI prefijo de espacio de nombres entidad interna XML 


<!ENTITY dsig11 


http: //www.w3.org/2009/xmldsig11# dsig11: 
à s S $ "http://ww.w3.0rg/2009/xmldsig11#"> 
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2. Descripción general y ejemplos de cifrado 


Esta sección no es normativa. 


Esta sección proporciona una descripción general y ejemplos de la sintaxis de cifrado XML. La sintaxis formal se encuentra en la sección 3. 
Sintaxis de cifrado ; el procesamiento específico se proporciona en las Reglas de procesamiento (sección 4). 


Expresado en forma abreviada, el EncryptedDataelemento tiene la siguiente estructura (donde "?" denota cero o una ocurrencia; "+" denota 
una o más ocurrencias; "*" denota cero o más ocurrencias; "|" denota una elección; y el elemento vacío etiqueta de elemento significa que el 
elemento debe estar vacío): 


EJEMPLO 1 


< Identificación de datos cifrados ? ¿Tipo ? ¿ Tipo Mime ? ¿ Codificación ? > <Método de cifrado/> ? 
<ds:KeyInfo> <Clave cifrada> ? 
<Método de acuerdo> ? 
<ds:NombreClave> ? 
<ds:MétododeRecuperación> ? 
<ds :* > ? 
</ds:KeyInfo> ? 
<DatosCifrado> <ValorCifrado> | < URI de referencia de cifrado ? > </CipherData> <EncryptionProperties> ? 
</EncryptedData> 


El CipherDataelemento envuelve o hace referencia a los datos cifrados sin procesar. Un CipherDataelemento debe tener un elemento 
secundario CipherValueo CipherReference. Si es envolvente, los datos cifrados sin procesar son el CipherValuecontenido del elemento; si 
se hace referencia, el atributo CipherReferencedel elemento URTapunta a la ubicación de los datos cifrados sin procesar 


2.1 Granularidad del cifrado 


Esta sección no es normativa. 


Nota: Los ejemplos de este documento no consideran ataques de adivinación de texto sin formato ni otros riesgos, y solo tienen fines 
ilustrativos. 


Considere la siguiente información de pago ficticia, que incluye información de identificación e información apropiada para un método de 
pago (por ejemplo, tarjeta de crédito, transferencia de dinero o cheque electrónico): 


EJEMPLO 2 
<? versión xml = "1.0" ?> 
<PaymentInfo xmlns = "http://example.org/paidv2" > <Nombre> John Smith </Nombre> < Limite de tarjeta de crédito = "5000" Mor 


Este margen representa que John Smith está usando su tarjeta de crédito con un límite de $5,000USD. 
2.1.1 Cifrar un elemento XML 


Esta sección no es normativa. 


¡El número de tarjeta de crédito de Smith es información confidencial! Si la aplicación desea mantener esa información confidencial, puede 
cifrar el CreditCardelemento: 


EJEMPLO 3 
<? versión xml = "1.0" ?> 


<PaymentInfo xmlns = "http://example.org/paidv2" > <Nombre> John Smith </Nombre> <EncryptedData Type = "http: //ww.w3.org/2C 


Al cifrar todo el CreditCardelemento desde sus etiquetas de inicio a fin, se oculta la identidad del elemento en sí. (Un espía no sabe si 
utilizó una tarjeta de crédito o una transferencia de dinero). El CipherDataelemento contiene la serialización cifrada del CreditCardelemento. 


2.1.2 Cifrado del contenido del elemento XML (Elementos) 
Como escenario alternativo, puede ser útil para los agentes intermediarios saber que John usó una tarjeta de crédito con un límite 


particular, pero no el número, el emisor y la fecha de vencimiento de la tarjeta. En este caso, el contenido (datos de caracteres o elementos 
secundarios) del CreditCardelemento se puede cifrar: 


EJEMPLO 4 
<? versión xml = "1.0" ?> 


<PaymentInfo xmlns = "http://example.org/paidv2" > <Nombre> John Smith </Nombre> < Limite de tarjeta de crédito = "5000" Mor 


2.1.3 Cifrado del contenido del elemento XML (datos de caracteres) 


Alternativamente, considere el escenario en el que toda la información, excepto el número de tarjeta de crédito real, puede estar clara, 
incluido el hecho de que existe el elemento Número: 


EJEMPLO 5 
<? versión xml = "1.0" ?> 
<PaymentInfo xmlns = "http://example.org/paidv2" > <Nombre> John Smith </Nombre> < Limite de tarjeta de crédito = "5000" Mor 


Ambos CreditCardy Numberestán claros, pero el contenido de los datos de caracteres Numberestá cifrado. 
2.1.4 Cifrado de datos arbitrarios y documentos XML 


Si el escenario de la aplicación requiere que toda la información esté cifrada, todo el documento se cifra como una secuencia de octetos. 
Esto se aplica a datos arbitrarios, incluidos documentos XML. 


EJEMPLO 6 
<? versión xml = "1.0" ?> 


<EncryptedData xmlns = "http://ww.w3.org/2001/04/xmlenc#" MimeType = "text/xml" > <CipherData> <CipherValue> A23B45C56 </Ci 


Cuando corresponda, como en el caso de cifrar un flujo EXI completo, SE DEBE proporcionar el atributo Tipo e indicar el uso de EXI. El 
MimeType opcional PUEDE usarse para registrar el tipo real (no codificado EXI), pero no es necesario y puede omitirse, como en el siguiente 
ejemplo de cifrado EXI: 


EJEMPLO 7 


<? versión xml = "1.0" ?> 


<EncryptedData xmlns = "http://ww.w3.org/2001/04/xmlenc#" Tipo = "http://ww.w3.org/2009/xmlenc11#EXI" > <CipherData> <Cipr 


2.1.5 Supercifrado: cifrado de datos cifrados 


Un documento XML puede contener cero o más EncryptedData elementos. EncryptedDatano puede ser padre o hijo de otro 
EncryptedDataelemento. Sin embargo, los datos reales cifrados pueden ser cualquier cosa, incluidos EncryptedDataelementos EncryptedKey 
(es decir, supercifrado). Durante el supercifrado de un elemento EncryptedDatao EncryptedKey, se debe cifrar todo el elemento. Cifrar solo el 
contenido de estos elementos o cifrar elementos secundarios seleccionados es una instancia no válida según el esquema proporcionado. 


Por ejemplo, considere lo siguiente: 


EJEMPLO 8 


<pay:PaymentInfo xmlns:pay = "http://example.org/paidv2" > <EncryptedData Id = "ED1" xmlns = "http: //ww.w3.org/2001/04/xmle 


Un supercifrado válido de " //xenc:EncryptedData[@Id='ED1']" sería: 


EJEMPLO 9 


<pay:PaymentInfo xmlns:pay = "http://example.org/paidv2" > <EncryptedData Id = "ED2" xmlns = "http://ww.w3.org/2001/04/xmle 


donde el CipherValuecontenido de ' newEncryptedData' es la codificación base64 de la secuencia de octetos cifrados resultante del cifrado 
del EncryptedDataelemento con Id='ED1'. 


2.2EncryptedData y EncryptedKeyuso 


2.2.1EncryptedData con clave simétrica ( KeyName) 


EJEMPLO 10 


[ s01 ]< EncryptedData xmlns = "http://ww.w3.org/2001/04/xmlenc#" Tipo = "http://www.w3.org/2001/04/xmlenc#Element" > [ s02 


[s05] </ ds : KeyInfo > [ s06 ] < CipherData >< CipherValue > DEADBEEF </CipherValue> < / CipherData > [ s07 ]</ EncryptedDz 


[s1]El tipo de datos cifrados se puede representar como un valor de atributo para ayudar en el descifrado y el procesamiento posterior. En 
este caso, los datos cifrados eran un "elemento". Otras alternativas incluyen el "contenido" de un elemento o una secuencia de octetos 
externa que también puede identificarse mediante los atributos MimeTypey Encoding. 

[s2]Este (3DES CBC) es un cifrado de clave simétrica. 


[s4]La clave simétrica tiene un nombre asociado "John Smith". 


[s6] CipherDatacontiene un CipherValue, que es una secuencia de octetos codificada en base64. Alternativamente, podría contener un 
CipherReference, que es una referencia de URI junto con las transformaciones necesarias para obtener los datos cifrados como una 
secuencia de octetos. 


2.2.2EncryptedKey ( ReferenceList, ds:RetrievalMethod, CarriedKeyName) 


La siguiente EncryptedDataestructura es muy similar a la anterior, excepto que esta vez se hace referencia a la clave mediante 
ds:RetrievalMethod: 
EJEMPLO 11 


[ t01 ]< Id. de datos cifrados = "ED" 
xmlns = "http://www.w3.org/2001/04/xmlenc#" > [ t02 ] < Algoritmo del método de cifrado = "http: //ww.w2 


[t06] </ ds : KeyInfo > [ t07 ] < CipherData >< CipherValue > DEADBEEF </CipherValue> < / CipherData > [ t08 ]</ EncryptedDz 


[t02]Este (AES-128-CBC) es un cifrado de clave simétrica. 
[t04] ds:RetrievalMethodse utiliza para indicar la ubicación de una clave con tipo xenc: EncryptedKey. La clave (AES) se encuentra en '#EK'. 


[t05] ds :KeyNameproporciona un método alternativo para identificar la clave necesaria para descifrar el archivo CipherData. Cualquiera o 
ambos ds: KeyNamey ds : KeyRetrievalMethod podrían usarse para identificar la misma clave. 


Dentro del mismo documento XML, existía una EncryptedKey estructura a la que se hacía referencia en [t04]: 


EJEMPLO 12 
t09 ]< Id. de clave cifrada = "EK" xmlns = "http: //ww.w3.org/2001/04/xmlenc+" > [ t10 ] < Algoritmo del método de cifradc 


t13] </ ds : KeyInfo > [ t14 ] < CipherData >< CipherValue > xyzabc </CipherValue> < / CipherData > [ t15 ] < Lista de refe 


t18] <CarriedKeyName>Sally Doe</ CarriedKeyName > [ t19 ]</ EncryptedKey > 


[t09]El EncryptedkKeyelemento es similar al EncryptedDataelemento excepto que los datos cifrados son siempre un valor clave. 
[t10]Es EncryptionMethodel algoritmo de clave pública RSA. 
[t12] ds: KeyNamede "John Smith" es una propiedad de la clave necesaria para descifrar (usando RSA) el archivo CipherData. 


[t14]El CipherData's CipherValue es una secuencia de octetos que es procesada (serializada, cifrada y codificada) por un objeto cifrado de 
referencia EncryptionMethod. (Tenga en cuenta que una EncryptedKey EncryptionMethodes el algoritmo utilizado para cifrar estos octetos y 
no habla de qué tipo de octetos son). 


[t15-17]A ReferenceListidentifica los objetos cifrados ( DataReferencey KeyReference) cifrados con esta clave. Contiene ReferenceListuna 
lista de referencias a datos cifrados por la clave simétrica contenida dentro de esta estructura. 


[t18]El CarriedkKeyNameelemento se utiliza para identificar el valor de la clave cifrada al que puede hacer referencia el KeyNameelemento en 
ds:KeyInfo. (Dado que los valores de los atributos de ID deben ser exclusivos de un documento, Carr iedkeyNamepuede indicar que varias 
EncryptedKeyestructuras contienen el mismo valor de clave cifrado para diferentes destinatarios). 


3. Sintaxis de cifrado 


Esta sección proporciona una descripción detallada de la sintaxis y las funciones del cifrado XML. Las características descritas en esta 
sección DEBEN implementarse a menos que se indique lo contrario. La sintaxis se define mediante [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] con 
el siguiente preámbulo XML, declaración, entidad interna e importación: 


Definición del esquema : 


<? versión xml = "1.0" codificación = "utf-8" ?> <!DOCTYPE esquema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" 


[ 

<!ATTLIST esquema 

xmlns:xenc CDATA #FIXED 'http://ww.w3.org/2001/04/xmlenc'# 

xmlns:ds CDATA #FIXED 'http://ww.w3.org/2000/09/xmldsig#'> <!ENTITY xenc ‘http://ww.w3.org/2001/04/xmlenc#'> <! ENTIDAD % p 


]> 


<esquema xmlns = "http://ww.w3.org/2001/XMLSchema" versión = "1.0" xmlns:ds = "http://ww.w3.org/2000/09/xmldsig#" xmlns:xenc 


<importar espacio de nombres = "http://www .w3.org/2000/09/xmldsig#" esquemaLocation = “http://ww.w3.org/TR/2002/ 
REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" /> 


(Nota: se agregó una nueva línea al URI de ubicación de esquema para que quepa en esta página, pero no forma parte del URI). 


El marcado adicional definido en esta especificación utiliza el xenc11:espacio de nombres. La sintaxis se define en un esquema XML con el 
siguiente preámbulo: 


Definición del esquema : 


<? versión xml = "1.0" codificación = "utf-8" ?> <!DOCTYPE esquema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" 


[ 

<!ATTLIST esquema 

xmlns:xenc CDATA #FIXED "http: //ww.w3.org/2001/04/xmlenc#" 

xmlns:ds CDATA #FIXED "http: //ww.w3.org/2000/09/xmldsig#" 

xmlns:xenc11 CDATA #FIXED "http://www.w3.org/2009/xmlenc11#"> <!ENTITY xenc "http://ww.w3.org/2001/04/xmlenc#"> <!ENTITY % p 


1> 


<esquema xmlns = "http://ww.w3.org/2001/XMLSchema" versión = "1.0" xmlns:xenc = "http://ww.w3.org/2001/04/xmlenc+t" xmlns:xen 


<importar espacio de nombres = "http: //ww.w3.org/2000/09/xmldsig+t" esquemaLocation = "http://ww.w3.org/TR/2002/ 
REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" /> 
<importar espacio de nombres = "http://www.w3.org/2001/04/xmlenc#" esquemaLocation = "http://ww.w3.org/TR/2002/ 


REC-xmlenc-core-20021210/xenc-schema.xsd" /> 
(Nota: se agregó una nueva línea al URI de ubicación de esquema para que quepa en esta página, pero no forma parte del URI). 


3.1 El EncryptedTypeelemento 


EncryptedTypees el tipo abstracto del que se derivan EncryptedDatay . EncryptedKeySi bien estos dos últimos tipos de elementos son muy 
similares con respecto a sus modelos de contenido, una distinción sintáctica es útil para el procesamiento. Las implementaciones DEBEN 
generar un esquema laxamente válido [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] EncryptedDatao Encryptedkeyelementos según lo especificado 
en las declaraciones de esquema posteriores. (Tenga en cuenta que la generación válida del esquema laxo significa que el contenido 
permitido xsd:ANYno necesita ser válido). Las implementaciones DEBEN crear estas estructuras XML ( EncryptedTypeelementos y sus 
descendientes/contenido) en el Formulario de normalización C [ NFC ]. 


Definición del esquema : 


<complexType nombre = "EncryptedType" abstract = "true" > <secuencia> <elemento nombre = "EncryptionMethod" tipo = "xenc:Encry 


EncryptionMethodes un elemento opcional que describe el algoritmo de cifrado aplicado a los datos cifrados. Si el elemento está ausente, el 
destinatario debe conocer el algoritmo de cifrado o el descifrado fallará. 


ds:KeyInfoes un elemento opcional, definido por [ XMLDSIG-CORE1 ], que transporta información sobre la clave utilizada para cifrar los 
datos. Las secciones posteriores de esta especificación definen nuevos elementos que pueden aparecer como hijos de ds: KeyInfo. 


CipherDataes un elemento obligatorio que contiene el CipherValueo CipherReferencecon los datos cifrados. 
EncryptionPropertiespuede contener información adicional sobre la generación del EncryptedType(por ejemplo, marca de fecha/hora). 


Ides un atributo opcional que proporciona el método estándar de asignar una identificación de cadena al elemento dentro del contexto del 
documento. 


Type is an optional attribute identifying type information about the plaintext form of the encrypted content. While optional, this specification 
takes advantage of it for processing described in section 4.4 Decryption. If the EncryptedData element contains data of Type 'element' or 
element ‘content’, and replaces that data in an XML document context, or contains data of Type 'EXI', it is strongly recommended the Type 
attribute be provided. Without this information, the decryptor will be unable to automatically restore the XML document to its original 
cleartext form. 


MimeType is an optional (advisory) attribute which describes the media type of the data which has been encrypted. The value of this attribute 
is a string with values defined by [RFC2045]. For example, if the data that is encrypted is a base64 encoded PNG, the transfer Encoding may 
be specified as ‘http://www.w3.org/2000/09/xmlidsig#base64' and the MimeType as ‘image/png’. This attribute is purely advisory; no 
validation of the MimeType information is required and it does not indicate the encryption application must do any additional processing. 
Note, this information may not be necessary if it is already bound to the identifier in the Type attribute. For example, the Element and 
Content types defined in this specification are always UTF-8 encoded text. In the case of Type EXI the MimeType attribute is not necessary, 
but if used should reflect the underlying type and not "EXI". 


Encoding is an optional (advisory) attribute which describes the transfer encoding of the data that has been encrypted. 


3.2 The Encrypt ionMethod Element 


EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the 
encryption algorithm must be known to the recipient or the decryption will fail. 


Schema Definition: 


<complexType name="Encryptionmethodtype" mixed="true"> 
<sequence> 
<element name="KeySize" minOccurs="0" type="xenc:KeySizeType"/> 
<element name="OAEPparams" minOccurs="0" type="base64Binary"/> 
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
<attribute name="Algorithm" type="anyURI" use="required"/> 
</complexType> 


The permitted child elements of the Encrypt ionMethod are determined by the specific value of the Algorithm attribute URI, and the KeySize 
child element is always permitted. For example, the RSA-OAEP algorithm (section 5.5.2 RSA-OAEP) uses the ds :DigestMethod and 
OAEPparams elements, and may use the xenc11:MGF element when needed. (We rely upon the ANY schema construct because it is not possible 
to specify element content based on the value of an attribute.) 


The presence of any child element under Encrypt ionMethod that is not permitted by the algorithm or the presence of a KeySize child 
inconsistent with the algorithm MUST be treated as an error. (All algorithm URIs specified in this document imply a key size but this is not 
true in general. Most popular stream cipher algorithms take variable size keys.) 


3.3 The CipherData Element 


The CipherData is a mandatory element that provides the encrypted data. It must either contain the encrypted octet sequence as base64 
encoded text as element content of the CipherValue element, or provide a reference to an external location containing the encrypted octet 
sequence via the CipherReference element. 


Schema Definition: 
<element name="CipherData" type="xenc:CipherDataType"/> 


<complexType name="CipherDataType"> 
<choice> 
<element name="CipherValue" type="base64Binary"/> 
<element ref="xenc:CipherReference"/> 
</choice> 
</complexType> 


3.3.1 The CipherReference Element 


If CipherValue is not supplied directly, the CipherReference identifies a source which, when processed, yields the encrypted octet sequence. 


The actual value is obtained as follows. The CipherReference URI contains an identifier that is dereferenced. Should the CipherReference 
element contain an OPTIONAL sequence of Transforms, the data resulting from dereferencing the URI is transformed as specified so as to 
yield the intended cipher value. For example, if the value is base64 encoded within an XML document; the transforms could specify an 
XPath expression followed by a base64 decoding so as to extract the octets. 


The syntax of the URI and Transforms is defined in XML Signature [XMLDSIG-CORE1], however XML Encryption places the Transforms 
element in the XML Encryption namespace since it is used in XML Encryption to obtain an octet stream for decryption. In [KMLDSIG-CORE1] 
both generation and validation processing start with the same source data and perform that transform in the same order. In encryption, the 
decryptor has only the cipher data and the specified transforms are enumerated for the decryptor, in the order necessary to obtain the 
octets. Consequently, because it has different semantics Transforms is in the xenc: namespace. 


For example, if the relevant cipher value is captured within a CipherValue element within a different XML document, the CipherReference 
might look as follows: 
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<CipherReference URI="http://ww.example.com/CipherValues.xml"> 
<Transforms> 
<ds:Transform Algorithm="http: //ww.w3.org/TR/1999/REC-xpath-19991116"> 
<ds:XPath xmlns:xenc="http: //ww.w3.org/2001/04/xmlenc#"> 
self: :text()[parent: :enc:CipherValue[@Id="example1"]] 
</ds :XPath> 
</ds:Transform> 
<ds:Transform Algorithm="http://ww.w3.org/2000/09/xml1dsigibase64"/> 
</Transforms> 
</CipherReference> 


Implementations MUST support the CipherReference feature and the same URI encoding, dereferencing, scheme, and HTTP response codes 
as that of [XMLDSIG-CORE1]. The Transform feature and particular transform algorithms are OPTIONAL. 


Schema Definition: 
<element name="CipherReference" type="xenc:CipherReferenceType"/> 


<complexType name="CipherReferenceType"> 
<sequence> 
<element name="Transforms" type="xenc:TransformsType" minOccurs="0"/> 
</sequence> 
<attribute name="URI" type="anyURI" use="required"/> 
</complexType> 


<complexType name="TransformsType"> 
<sequence> 
<element ref="ds:Transform" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


3.4 The EncryptedData Element 
The EncryptedData element is the core element in the syntax. Not only does its CipherData child contain the encrypted data, but it's also the 
element that replaces the encrypted element, or element content, or serves as the new document root. 
Schema Definition: 
<element name="EncryptedData" type="xenc:EncryptedDataType"/> 
<complexType name="EncryptedDataType"> 
<complexContent> 
<extension base="xenc:EncryptedType"> 
</extension> 


</complexContent> 
</complexType> 


3.5 Extensions to ds: KeyInfo Element 


There are three ways that the keying material needed to decrypt CipherData can be provided: 


1. El elemento EncryptedDatao EncryptedKeyespecifica el material de clave asociado a través de un elemento secundario de ds: KeyInfo. 
Todos los elementos secundarios de ds: keyInfoespecificados en [ XMLDSIG-CORE1 ] PUEDEN usarse como calificados: 


1. La compatibilidad con ds : KeyValuees OPCIONAL y se puede utilizar para transportar claves públicas, como valores clave Diffie- 
Hellman ( sección 5.6.1 Valores clave Diffie-Hellman ). (OBVIAMENTE NO SE RECOMIENDA incluir la clave de descifrado de texto sin 
formato, ya sea una clave privada o secreta ). 

2. Se RECOMIENDA el soporte de ds : KeyNamepara hacer referencia a un .EncryptedKey CarriedKeyName 

3. ds:RetrievalMethodSe REQUIERE soporte para el mismo documento . 


Además, proporcionamos dos elementos secundarios adicionales: las aplicaciones DEBEN ser compatibles EncryptedKey ( sección 
3.5.1 El elemento EncryptedKey ) y PUEDEN ser compatibles AgreementMethod ( sección 5.6 Acuerdo de clave ). 

2. Un elemento separado (no dentro ds:keyInfo) EncryptedkKeypuede especificar el EncryptedDatao EncryptedKeyal cual se aplicará su 
clave descifrada a través de un DataReferenceo KeyReference( sección 3.6 El elemento ReferenceList ). 

3. El material de claves lo puede determinar el destinatario según el contexto de la aplicación y, por lo tanto, no es necesario 
mencionarlo explícitamente en el XML transmitido. 


3.5.1 El EncryptedKeyelemento 


Identificador 
Type="http://ww.w3.org/2001/04/xmlenc#EncryptedKey" 


(Esto se puede usar dentro de un ds:RetrievalMethodelemento para identificar el tipo de referente). 


El EncryptedKeyelemento se utiliza para transportar claves de cifrado desde el origen hasta uno o varios destinatarios conocidos. Puede 
usarse como un documento XML independiente, colocarse dentro de un documento de aplicación o aparecer dentro de un 
EncryptedDataelemento como hijo de un ds :KeyInfo elemento. El valor de la clave siempre está cifrado para los destinatarios. Cuando 
EncryptedKeyse descifra, los octetos resultantes se ponen a disposición del EncryptionMethodalgoritmo sin ningún procesamiento 
adicional. 


Definición del esquema : 
< nombre del elemento = "EncryptedKey" tipo = "xenc:EncryptedKeyType" /> 


<complexType nombre = "EncryptedKeyType" > <complexContent> <extensión base = "xenc:EncryptedType" > <secuencia> <elemento ref 


ReferenceListes un elemento opcional que contiene punteros a datos y claves cifradas con esta clave. La lista de referencias puede 
contener múltiples referencias EncryptedKkeyy EncryptedDataelementos. Esto se hace usando elementos KeyReferencey 
DataReferencerespectivamente. Estos se definen a continuación. 


CarriedKeyNamees un elemento opcional para asociar un nombre legible por el usuario con el valor clave. Esto luego se puede usar para 
hacer referencia a la clave usando el ds: KeyNameelemento dentro de ds: KeyInfo. La misma CarriedkKeyNameetiqueta, a diferencia de un tipo 
de identificación, puede aparecer varias veces dentro de un solo documento. El valor de la clave DEBE ser el mismo en todos 
EncryptedKeylos elementos identificados con la misma CarriedkKeyNameetiqueta dentro de un único documento XML. Tenga en cuenta que 
debido a que los espacios en blanco son significativos en el valor del ds : KeyName elemento, los espacios en blanco también son 
significativos en el valor del CarriedkKeyNameelemento. 


Recipientes un atributo opcional que contiene una pista sobre a qué destinatario está destinado este valor de clave cifrada. Su contenido 
depende de la aplicación. 


El Typeatributo heredado de EncryptedType se puede utilizar para especificar aún más el tipo de clave cifrada si EncryptionMethod 
Algorithmno define una codificación/representación inequívoca. (Tenga en cuenta que todos los algoritmos de esta especificación tienen 
una representación inequívoca para sus estructuras clave asociadas). 


3.5.2 El DerivedKeyelemento 


Identificador 
Type="http: //www.w3.org/2009/xmlenc11#DerivedKey" 


(Esto se puede usar dentro de un ds:RetrievalMethodelemento para identificar el tipo de referente). 


El Der ivedkeyelemento se utiliza para transportar información sobre una clave derivada desde el origen hasta los destinatarios. Puede 
usarse como un documento XML independiente, colocarse dentro de un documento de aplicación o aparecer dentro de un elemento 
EncryptedDatao Signaturecomo hijo de un ds: KeyInfo elemento. El valor clave en sí nunca lo envía el autor. Más bien, el originador 
proporciona información a los destinatarios mediante la cual los destinatarios pueden obtener el mismo valor clave. Cuando se ha obtenido 
la clave, los octetos resultantes se ponen a disposición del algoritmo EncryptionMethodo SignatureMethodsin ningún procesamiento 
adicional. 


Definición del esquema : 
<!-- targetNamespace='http://ww.w3.org/2009/xmlenc11#' --> 
< nombre del elemento = "DerivedKey" tipo = "xenc11:DerivedKeyType" /> 


<complexType nombre = "DerivedKeyType" > <secuencia> <elemento ref = "xenc11:KeyDerivationMethod" minOccurs = "0" /> <elementc 


< nombre del elemento = "KeyDerivationMethod" tipo = "xenc:KeyDerivationMethodType" /> 


<complexType nombre = "KeyDerivationMethodType" > <secuencia> <cualquier espacio de nombres = "##cualquier" minOccurs = "0" ma 


KeyDerivationMethodes un elemento opcional que describe el algoritmo de derivación de claves aplicado al material de clave maestra 
(subyacente). Si el elemento está ausente, el destinatario debe conocer el algoritmo de derivación de claves o la derivación de claves del 
destinatario fallará. 


ReferenceListes un elemento opcional que contiene punteros a datos y claves cifradas con esta clave. La lista de referencias puede 
contener múltiples referencias EncryptedKeyo EncryptedDataelementos. Esto se hace utilizando KeyReferenceelementos DataReferencede 
XML Encryption. 


El elemento opcional DerivedkKeyNamese utiliza para identificar el valor clave derivado. Este elemento puede entonces ser referenciado por el 
ds: KeyNameelemento en ds: KeyInfo. La misma DerivedKeyNameetiqueta, a diferencia de un tipo de identificación, puede aparecer varias 
veces dentro de un solo documento. Tenga en cuenta que debido a que los espacios en blanco son significativos en el valor del 

ds : KeyNameelemento, los espacios en blanco también son significativos en el valor del Der ivedkeyNameelemento. 


MasterKeyNamees un elemento opcional para asociar un nombre legible por el usuario con el valor de la clave maestra (o secreta). La misma 
MasterKeyNameetiqueta, a diferencia de un tipo de identificación, puede aparecer varias veces dentro de un solo documento. El valor de la 
clave maestra DEBE ser el mismo en todos DerivedkKeylos elementos identificados con la misma MasterKeyNameetiqueta dentro de un único 
documento XML. Si no MasterKeyNamese proporciona, el destinatario debe conocer el material de la clave maestra o la derivación de la clave 
fallará. 


Recipientes un atributo opcional que contiene una pista sobre a qué destinatario está destinado este valor de clave derivada. Su contenido 
depende de la aplicación. 


El Idatributo opcional proporciona el método estándar para asignar una identificación de cadena al elemento dentro del contexto del 
documento. 


El Typeatributo se puede utilizar para especificar aún más el tipo de clave derivada si el keyDerivationMethod algoritmo no define una 
codificación/representación inequívoca. 


3.5.3 El ds:RetrievalMethodelemento 


El con a de '' proporciona una manera de expresar un enlace a un elemento que contiene la clave necesaria para descifrar el elemento 
asociado con un o . El con a de '' proporciona una forma de expresar un vínculo a un elemento utilizado para derivar la clave necesaria para 
descifrar el elemento asociado con un o . El con uno de estos tipos siempre es hijo del elemento y puede aparecer varias veces. Si hay más 
de una instancia de a de este tipo, entonces los objetos a los que se hace referencia deben contener el mismo valor de clave, posiblemente 
cifrado de diferentes maneras o para diferentes destinatarios.ds:RetrievalMethod [XMLDSIG- 

CORE1]Typehttp: //ww.w3.org/2001/04/xmlenc#EncryptedKeyEncryptedKeyCipherDataEncryptedDataEncryptedKeyds :RetrievalMethod 
[XMLDSIG- 


CORE1]Typehttp: //ww.w3.org/2001/04/xmlenc#DerivedKeyDer ivedKeyCipherDataEncryptedDataEncryptedKeyds :RetrievalMethodds : KeyInfods: 


3.6 El ReferenceListelemento 


ReferenceListes un elemento que contiene punteros desde un valor clave de EncryptedKeyo DerivedKeya elementos cifrados por ese valor 
clave ( EncryptedDatao EncryptedKeyelementos). 


Definición del esquema : 


< nombre del elemento = "ReferenceList" > <tipocomplejo> <elección minOccurs = "1" maxOccurs = "ilimitado" > < nombre del eler 


<complexType nombre = "Tipo de referencia" > <secuencia> <cualquier espacio de nombres = "##otro" minOccurs = "0" maxOccurs 


DataReferenceLos elementos se utilizan para referirse a EncryptedDataelementos que se cifraron utilizando la clave definida en el elemento 
EncryptedKeyadjunto Der ivedkey. Pueden aparecer varios DataReferenceelementos si EncryptedDataexisten varios elementos cifrados con 
la misma clave. 


KeyReferenceLos elementos se utilizan para referirse a EncryptedkKeyelementos que se cifraron utilizando la clave definida en el elemento 
EncryptedKeyadjunto DerivedKey. Pueden aparecer varios KeyReferenceelementos si EncryptedKeyexisten varios elementos cifrados con la 
misma clave. 


Para ambos tipos de referencias, se pueden especificar opcionalmente elementos secundarios para ayudar al destinatario a recuperar los 
elementos EncryptedKeyy/o EncryptedData. Estos podrían incluir información como transformaciones XPath, transformaciones de 
descompresión o información sobre cómo recuperar los elementos de una instalación de almacenamiento de documentos. Por ejemplo: 
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<ReferenceList> <DataReference URI = "#invoice34" > <ds:Transforms> <ds:Transform Algorithm = "http: //ww.w3.org/TR/1999/REC 


self: :xenc:EncryptedData[@Id="ejemplo1"] 
</ds:XPath> </ds:Transform> </ds:Transforms> </DataReference> </ReferenceList> 


3.7 El EncryptionPropertieselemento 


Identificador 
Type="http://ww.w3.org/2001/04/xmlenc#EncryptionProperties" 


(Esto se puede usar dentro de un ds:Referenceelemento para identificar el tipo de referente). 


Se pueden colocar elementos de información adicional relacionados con la generación de EncryptedDatao en un elemento (por ejemplo, 
marca de fecha/hora o el número de serie del hardware criptográfico utilizado durante el cifrado). El atributo identifica la estructura que se 
describe. permite la inclusión de atributos del espacio de nombres XML que se incluirán (es decir, , y 
).EncryptedKeyEncryptionPropertyTargetEncryptedTypeanyAttributexml:spacexml:langxml : base 


Definición del esquema : 


< nombre del elemento = "EncryptionProperties" tipo = "xenc:EncryptionPropertiesType" /> 

<complexType nombre = "EncryptionPropertiesType" > <secuencia> <elemento ref = "xenc:EncryptionProperty" maxOccurs = "ilimitad 
< nombre del elemento = "EncryptionProperty" tipo = "xenc:EncryptionPropertyType" /> 

<complexType nombre = "EncryptionPropertyType" mixto = "verdadero" > <choice maxOccurs = "ilimitado" > <cualquier espacio de n 


4. Reglas de procesamiento 


Esta sección describe las operaciones que se realizarán como parte del procesamiento de cifrado y descifrado mediante implementaciones 
de esta especificación. Los requisitos de conformidad se especifican en los siguientes roles: 


cifrador 

Una implementación de cifrado XML con la función de cifrar datos. 
Descifrador 

Una implementación de cifrado XML con la función de descifrar datos. 


La aplicación invoca Encryptor y Decryptor . Esta especificación no incluye definiciones normativas para el comportamiento de las 
aplicaciones. Sin embargo, esta especificación incluye requisitos de conformidad sobre datos cifrados que solo pueden lograrse mediante 
un comportamiento apropiado por parte de las tres partes. Depende de los contextos de implementación específicos cómo se logra esto. 


4.1 Modelo de aplicación previsto 


Las reglas de procesamiento para el cifrado XML están diseñadas en torno a un modelo de aplicación previsto que esta versión de la 
especificación no cubre normativamente. 


En el modelo de procesamiento previsto, el cifrado XML se utiliza para cifrar una secuencia de octetos, una secuencia EXI o un fragmento 
de un documento XML que coincide con la contentproducción element de [ XML10 ]. 


Si se utiliza el cifrado XML con algún flujo de octetos, la codificación y el significado precisos de ese flujo de octetos dependen de la 
aplicación, pero el cifrador o el descifrador lo tratan como opaco. La aplicación puede utilizar los parámetros Type, Encodingy MimeTypepara 
transportar más información sobre la naturaleza de ese flujo de octetos. Por lo tanto, un Typeparámetro desconocido, en general, no es 
tratado como un error ni por el cifrador ni por el descifrador, sino que simplemente lo pasa junto con los demás parámetros pertinentes y el 
flujo de octetos de texto sin cifrar. 


Si se utiliza el cifrado XML con XML elemento XML content, los cifradores y descifradores suelen realizar un procesamiento específico del 
tipo: 


e Si un elementestá cifrado, entonces Encryptor reemplazará el elemento en cuestión con un EncryptedDataelemento construido 
apropiadamente. El Decryptor, por el contrario, reemplazará el EncryptedDataelemento con su texto sin cifrar. 

e Si XML contentestá cifrado, el Encryptor también reemplazará este contenido con un EncryptedDataelemento construido 
apropiadamente y el Decryptor revertirá esta operación. 


Tenga en cuenta que el comportamiento previsto de Encryptor a menudo hará que el documento con partes cifradas deje de ser válido con 
respecto a su esquema para el formato XML de alojamiento, a menos que ese formato esté específicamente preparado para usarse con 
XML Encryption. NO SE REQUIERE un cifrador o descifrador que implemente el modelo de procesamiento previsto para garantizar que el XML 
resultante tenga un esquema válido para el formato XML de alojamiento. 


Si el procesamiento XML se maneja dentro de Encryptor y Decryptor, y se utilizan los Typevalores de atributos para elementy texto sin cifrar, 
entonces Encryptor y Decryptor DEBEN garantizar que el texto sin cifrar XML se serialice como UTF-8 antes del cifrado y, si es necesario, se 
vuelva a convertir. a cualquier otra codificación que pueda ser utilizada por el contexto XML circundante.content 


Si se utiliza el cifrado XML con una secuencia EXI [ EXI ], los cifradores y descifradores procesan el contenido como para el procesamiento 
de elementos XML o contenido XML, pero teniendo en cuenta la serialización EXI. En particular, el cifrador reemplazará el elemento XML o 


el fragmento XML en cuestión con un elemento EncryptedData construido adecuadamente. Por el contrario, Decryptor reemplazará el 
elemento EncryptedData con su elemento XML de texto sin formato o fragmento XML. Tenga en cuenta que el documento XML en el que 
está incrustado el elemento EncryptedData puede codificarse usando EXI y/o EXI puede usarse para codificar el texto sin cifrar antes del 
cifrado. 


4.2Type Valores de parámetros conocidos 


PARA FINES DE INTEROPERABILIDAD, DEBEN implementarse los siguientes tipos de modo que una implementación pueda tomar como entrada 
y producir como salida datos que coincidan con las reglas de producción 39 y 43 de [ XML10]: 


elemento ' http: //www.w3.org/2001/04/xmlenc+tElement ' 
"[39] elemento ::= EmptyElemTag | Contenido de STag ETag " 
contenido ' http://www.w3.org/2001/04/xmlenc#Content ' 
"[43] contenido ::= CharData? (( elemento | Referencia | CDSect | PI | Comentario ) CharData?)*" 


La compatibilidad con el siguiente tipo es OPCIONAL para Encryptors y Decryptors: 

http://www.w3.org/2009/xmlenc11#EXI 
La presencia de esto Typeindica que el texto sin cifrar es una secuencia EXI [ EXI]. Los cifradores y descifradores que admiten este 
tipo PUEDEN operar directamente en (partes de) flujos EXI. 


Los cifradores y descifradores DEBEN manejar valores de atributos desconocidos o vacíos Typecomo señal de que el texto sin cifrar debe 
manejarse como un flujo de octetos opaco, cuyo procesamiento específico depende de la aplicación que lo invoca. En este caso, los 
parámetros Type, MimeTypey DEBEN tratarse como datos opacos cuyo procesamiento apropiado depende de la aplicación.Encoding 


4.3 Cifrado 


La selección del algoritmo, los parámetros y las claves de cifrado está fuera del alcance de esta especificación. 


Se supone que los datos en texto claro están presentes como un tren de octetos. Si el texto sin formato es de tipo elemento content, los 
datos DEBEN serializarse en UTF-8 como se especifica en [ XML10 ], utilizando la forma normal C [ NFC ]. 


Para que cada elemento de datos se cifre como elemento EncryptedDatao EncryptedKey, el cifrador DEBE : 
1. Obtener (o derivar) y (opcionalmente) representar la clave. 


1. Si la clave debe identificarse (mediante nombre, URI o incluirse en un elemento secundario), construya la clave ds : KeyInfosegun 
corresponda (p. ej. ds: KeyName, ds: KeyValue, ds: RetrievalMethod, etc.) 


2. Si se va a cifrar la clave en sí, construya un EncryptedKeyelemento aplicando recursivamente este proceso de cifrado. El 
resultado puede ser hijo de ds:keyInfoo puede existir en otro lugar y puede identificarse en el paso anterior. 


3. Si la clave se derivó de una clave maestra, construya un Der ivedkeyelemento con elementos secundarios asociados. El 
resultado puede, como en este EncryptedKey caso, ser hijo de ds: KeyInfoo puede existir en otro lugar. 


2. Cifre los datos: 
1. Cifre los octetos utilizando el algoritmo y la clave. 


2. A menos que el descifrador conozca implícitamente el tipo de datos cifrados, el cifrado DEBE configurar Typepara indicar la 
interpretación prevista de los datos de texto sin cifrar. Consulte la sección 4.2 Valores de parámetros de tipo conocido para 
obtener valores de parámetros conocidos. 


Si los datos son una secuencia de octetos simple, PUEDEN describirse con los atributos MimeTypey Encoding. Por ejemplo, los 
datos pueden ser un documento XML (MimeType="text/xml"), una secuencia de caracteres ( MimeType="text/plain") o datos de 
imagen binaria ( MimeType=" image/png"). 


3. Construya la estructura EncryptedDatao EncryptedKey: 


Una estructura EncryptedDatao EncryptedKeyrepresenta toda la información analizada anteriormente, incluido el tipo de datos 
cifrados, el algoritmo de cifrado, los parámetros, la clave, el tipo de datos cifrados, etc. 


1. Si la secuencia de octetos cifrada obtenida en el paso 2 se va a almacenar en el CipherDataelemento dentro del elemento 
EncryptedDatao EncryptedKey, entonces la representación en base64 de la secuencia de octetos cifrada se inserta como 
contenido de un CipherValueelemento. 


2. Si la secuencia de octetos cifrados se almacena externamente al elemento EncryptedDatao EncryptedKey, entonces el URI y las 


transformaciones (si las hay) necesarias para que el Decryptor recupere la secuencia de octetos cifrados se describen dentro de 
un CipherReferenceelemento. 


4.4 Descifrado 


Para cada uno EncryptedDatao EncryptedKeypara ser descifrado, el descifrador DEBE : 


1. Determinar el algoritmo, parámetros e información clave a utilizar. Esta información puede obtenerse fuera de banda o determinarse 
según un ds: KeyInfoelemento; consulte la sección 3.5 Extensiones del elemento ds:Keyinfo . 


2. Descifre los datos contenidos en el CipherDataelemento. 


1. Si hay un CipherValueelemento secundario presente, entonces se recupera el valor de texto asociado y se decodifica en base64 
para obtener la secuencia de octetos cifrada. 


2. If a CipherReference child element is present, the URI and transforms (if any) are used to retrieve the encrypted octet sequence. 


3. The encrypted octet sequence is decrypted using the algorithm, parameters and key value already determined from step 1. 


4.5 XML Encryption 


Encryption and decryption operations are operations on octets. The application is responsible for the marshalling XML such that it can be 
serialized into an octet sequence, encrypted, decrypted, and be of use to the recipient. 


For example, if the application wishes to canonicalize its data or encode/compress the data in an XML packaging format, the application 
needs to marshal the XML accordingly and identify the resulting type via the EncryptedData Type attribute. The likelihood of successful 
decryption and subsequent processing will be dependent on the recipient's support for the given type. Also, if the data is intended to be 
processed both before encryption and after decryption (e.g., XML Signature [XMLDSIG-CORE1] validation or an XSLT transform) the 
encrypting application must be careful to preserve information necessary for that process's success. 


The following sections contain specifications for decrypting, replacing, and serializing XML content (i.e., Type ‘element’ or element 'content') 
using the [XPATH] data model. These sections are non-normative and OPTIONAL to implementers of this specification, but they may be 
normatively referenced by and be required by other specifications that require a consistent processing for applications, such as [XMLENC- 
DECRYPT]. 


4.5.1 A Decrypt Implementation (Non-normative) 
Where P is the context in which the serialized XML should be parsed (a document node or element node) and O is the octet sequence 


representing UTF-8 encoded characters resulting from step 4.3 in section 4.4 Decryption. Y is node-set representing the decrypted content 
obtained by the following steps: 


1. Let C be the parsing context of a child of P, which consists of the following items: 
o Prefix and namespace name of each namespace that is in scope for P. 
o Name and value of each general entity that is effective for the XML document causing P. 
2. Wrap the decrypted octet stream O in the context C as specified in section 4.5.4 Text Wrapping. 
3. Parse the wrapped octet stream as described in The Reference Processing Model (section 4.3.3.2) of [KMLDSIG-CORE1], resulting in a 
node-set. 
4. Y is the node-set obtained by removing the root node, the wrapping element node, and its associated set of attribute and namespace 
nodes from the node-set obtained in Step 3. 


4.5.2 A Decrypt and Replace Implementation (Non-normative) 


Where X is the [XPATH] node set corresponding to an XML document and e is an EncryptedData element node in X. 


1. Z is an [XPATH] node-set that identical to X except where the element node e is an EncryptedData element type. In which case: 
1. Decrypt e in the context of its parent node as specified in the section 4.5.1 A Decrypt Implementation (Non-normative) yielding Y, 
an [XPATH] node set. 
2. Include Y in place of e and its descendants in X. Since [XPATH] does not define methods of replacing node-sets from different 
documents, the result MUST be equivalent to replacing e with the octet stream resulting from its decryption in the serialized form 
of X and re-parsing the document. However, the actual method of performing this operation is left to the implementor. 


4.5.3 Serializing XML (Non-normative) 
4.5.3.1 Default Namespace Considerations 


In section 4.3 Encryption (step 3.1), when serializing an XML fragment special care SHOULD be taken with respect to default namespaces. If 
the data will be subsequently decrypted in the context of a parent XML document then serialization can produce elements in the wrong 
namespace. Consider the following fragment of XML: 


EXAMPLE 15 


<Document xmlns="http://example.org/"> 
<ToBeEncrypted xmlns="" /> 
</Document> 


Serialization of the element ToBeEncrypted fragment via [XML-C14N] would result in the characters "<ToBeEncrypted></ToBeEncrypted>" as 
an octet stream. The resulting encrypted document would be: 


EXAMPLE 16 
<Document xmlns="http://example.org/"> 
<EncryptedData xmlns="..."> 
<!-- Containing the encrypted "<ToBeEncrypted></ToBeEncrypted>" --> 
</EncryptedData> 
</Document> 


Decrypting and replacing the EncryptedData within this document would produce the following incorrect result: 


EXAMPLE 17 


<Document xmlns="http://example.org/"> 
<ToBeEncrypted/> 
</Document> 


This problem arises because most XML serializations assume that the serialized data will be parsed directly in a context where there is no 
default namespace declaration. Consequently, they do not redundantly declare the empty default namespace with an xmins="". If, however, 
the serialized data is parsed in a context where a default namespace declaration is in scope (e.g., the parsing context as described in 
section 4.5.1 A Decrypt Implementation (Non-normative)), then it may affect the interpretation of the serialized data. 


To solve this problem, a canonicalization algorithm may be augmented as follows for use as an XML encryption serializer: 


e A default namespace declaration with an empty value (i.e., xmlns="") SHOULD be emitted where it would normally be suppressed by the 
canonicalization algorithm. 


While the result may not be in proper canonical form, this is harmless as the resulting octet stream will not be used directly in a [XMLDSIG- 
CORE1] signature value computation. Returning to the preceding example with our new augmentation, the ToBeEncrypted element would be 
serialized as follows: 


<ToBeEncrypted xmlns=""></ToBeEncrypted> 
When processed in the context of the parent document, this serialized fragment will be parsed and interpreted correctly. 
Este aumento se puede aplicar retroactivamente a una implementación de canonicalización existente canonicalizando cada nodo vértice y 


sus descendientes del conjunto de nodos, insertándolos xm1ns=""en los puntos apropiados y concatenando los flujos de octetos 
resultantes. 


4.5.3.2 Consideraciones sobre los atributos XML 


Se debe prestar una atención similar entre la relación de un fragmento y el contexto en el que se inserta a los atributos, y como se 
menciona en las xml :baseConsideraciones xml : langde seguridad de [ XML-EXC-C14N ]. Por ejemplo, si el elemento:xml : space 


EJEMPLO 18 


<Bongo href = "ejemplo.xml" /> 


se toma de un contexto y se serializa sin atributo xm1:base[ XMLBASE ] y se analiza en el contexto del elemento: 


EJEMPLO 19 


<Baz xml:base = "http://ejemplo.org/" /> 


el resultado sera: 


EJEMPLO 20 


<Baz xml:base = "http://example.org/" ><Bongo href = "ejemplo.xml" /></Baz> 


Bongo's hrefse interpreta posteriormente como " http: //example.org/example. xml". Si este no es el URI correcto, Bongodebería haberse 
serializado con su propio xml :baseatributo. 


Desafortunadamente, la recomendación de que se emita un valor vacío para separar el espacio de nombres predeterminado del fragmento 
del contexto en el que se inserta no se puede realizar para los atributos xml :basey xml: space. ( El error 41 de la errata de especificación 
XML 1.0 de segunda edición aclara que un valor de cadena vacío del atributo xml : lang se considera como si "no hubiera información de 
idioma disponible, como si xml: langno se hubiera especificado".) La interpretación de un valor vacío para los atributos xml :baseo 

xml: spaceno están definidos o mantienen el valor contextual. En consecuencia, las aplicaciones DEBEN garantizar (1) que los fragmentos 
que se van a cifrar no dependan de atributos XML, o (2) si son dependientes y se pretende que el documento resultante sea válido [XML10], 
la definición del fragmento permite la presencia del atributos y que los atributos tengan valores no vacíos. 


4.5.4 Ajuste de texto 


Esta sección especifica el proceso para ajustar texto en un contexto de análisis determinado. El proceso se basa en la propuesta de 
Richard Tobin [ Tobin ] para construir el conjunto de información [ XML-INFOSET ] de una entidad externa. 


El proceso consta de los siguientes pasos: 


1. Si el contexto de análisis contiene entidades generales, emita una declaración de tipo de documento que proporcione declaraciones 
de entidades. 


2. Emita una dummyetiqueta de inicio de elemento con atributos de declaración de espacio de nombres que declaren todos los espacios 
de nombres en el contexto de análisis. 


3. Emitir el texto. 

4. Emitir una dummyetiqueta final de elemento. 
En los pasos anteriores, la declaración del tipo de documento y dummy las etiquetas de elementos DEBEN codificarse en UTF-8. 
Considere el siguiente documento que contiene un EncryptedData elemento: 
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<!DOCTYPE Documento [ 

<!ENTITY dsig "http: //ww.w3.org/2000/09/xmldsig+t"> 

|> 

<Documento xmlns = "http://example.org/" > <foo:Body xmlns:foo = "http://example.org/foo" > <EncryptedData xmlns = "http://w 


</EncryptedData> </foo:Body> </Documento> 


Si el EncryptedDataelemento se descifra al texto " <One><foo: Two/></One>", entonces el formato ajustado es el siguiente: 


EJEMPLO 22 


<!DOCTYPE ficticio [ 

<!ENTITY dsig "http: //ww.w3.org/2000/09/xmldsig+t"> 

]> 

<dummy xmlns = "http://example.org/" xmlns:foo = "http://example.org/foo" > <Uno> <foo:Dos/> </Uno> </dummy> 


5. Algoritmos 


Esta sección analiza los algoritmos utilizados con la especificación de cifrado XML. Las entradas contienen el identificador que se utilizará 
como valor del Algorithmatributo del EncryptionMethodelemento u otro elemento que represente el rol del algoritmo, una referencia a la 
especificación formal, definiciones para la representación de claves y los resultados de las operaciones criptográficas cuando corresponda, 
y información general. comentarios de aplicabilidad. 


5.1 Identificadores de algoritmos y requisitos de implementación 


Todos los algoritmos enumerados a continuación tienen parámetros implícitos según su función. Por ejemplo, los datos que se van a cifrar 
o descifrar, el material de claves y la dirección de operación (cifrado o descifrado) de los algoritmos de cifrado. Cualquier parámetro 
adicional explícito de un algoritmo aparece como elementos de contenido dentro del elemento. Dichos elementos secundarios de 
parámetros tienen nombres de elementos descriptivos, que frecuentemente son específicos del algoritmo, y DEBEN estar en el mismo 
espacio de nombres que esta especificación de cifrado XML, la especificación de firma XML o en un espacio de nombres específico del 
algoritmo. Un ejemplo de un parámetro tan explícito podría ser un nonce (cantidad única) proporcionado a un algoritmo de acuerdo clave. 


Esta especificación define un conjunto de algoritmos, sus URI y requisitos de implementación. Los niveles de requisitos especificados, 
como " REQUERIDO " u " OPCIONAL ", se refieren a la implementación, no al uso. Además, el mecanismo es extensible y se pueden utilizar 
algoritmos alternativos. 


5.1.1 Tabla de algoritmos 


La siguiente tabla enumera las categorías de algoritmos. Dentro de cada categoría, se proporciona un nombre breve, el nivel de requisito de 
implementación y un URI de identificación para cada algoritmo. 


Cifrado de bloques 


1. TRIPLEDES REQUERIDOS 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc 
2. AES-128 REQUERIDO 
http://www.w3.org/2001/04/xmlenc#aes128-cbc 
3. AES-256 REQUERIDO 
http://www.w3.org/2001/04/xmlenc#aes256-cbc 
4. AES128-GCM REQUERIDO 
http://www.w3.org/2009/xmlenc11#aes128-gcm 
5. OPCIONAL AES-192 
http://www.w3.org/2001/04/xmlenc#aes192-cbc 
6. OPCIONAL AES192-GCM 
http://www.w3.org/2009/xmlenc11#aes192-gem 
7. OPCIONAL AES256-GCM 
http://www.w3.org/2009/xmlenc11#aes256-gcm 


Nota: Se recomienda encarecidamente el uso de AES GCM sobre cualquier algoritmo de cifrado de bloques CBC, ya que los avances 
recientes en criptoanálisis [ XMLENC-CBC-ATTACK ][ XMLENC-CBC-ATTACK-COUNTERMEASURES ] han puesto en duda la capacidad 
de los algoritmos de cifrado de bloques CBC para proteger datos simples. texto cuando se utiliza con cifrado XML. Se deben 
considerar otras mitigaciones al utilizar el cifrado de bloques CBC, como transmitir los datos cifrados a través de un canal seguro 
como TLS. Los algoritmos de cifrado de bloques CBC que se enumeran como necesarios siguen siéndolo por motivos de 
compatibilidad con versiones anteriores. 


Cifrado de flujo 


1. none 
Syntax and recommendations are given below to support user specified algorithms. 


Key Derivation 


1. REQUIRED ConcatKDF 
http://www.w3.org/2009/xmlenc11#ConcatKDF 

2. OPTIONAL PBKDF2 
http://www.w3.org/2009/xmlenc11#pbkdf2 


Key Transport 


1. REQUIRED RSA-OAEP (including MGF1 with SHA1) 
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p 

2. Optional RSA-OAEP 
http://www.w3.org/2009/xmlenc11#rsa-oaep 

3. OPTIONAL RSA-v1.5 (see RSA-v1.5 security note) 
http://www.w3.org/2001/04/xmlenc#rsa-1_5 


Key Agreement 


1. REQUIRED Elliptic Curve Diffie-Hellman (Ephemeral-Static mode) 
http://www.w3.org/2009/xmlenc11#ECDH-ES 

2. OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with Legacy Key Derivation Function 
http://www.w3.org/2001/04/xmlenc#dh 

3. OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with explicit Key Derivation Functions 


http://www.w3.org/2009/xmlenc11#dh-es 


Symmetric Key Wrap 


1. REQUIRED TRIPLEDES KeyWrap 
http://www.w3.org/2001/04/xmlenc#kw-tripledes 
2. REQUIRED AES-128 KeyWrap 
http://www.w3.org/2001/04/xmlenc#kw-aes128 
3. REQUIRED AES-256 KeyWrap 
http://www.w3.org/2001/04/xmlenc#kw-aes256 
4. OPTIONAL AES-192 KeyWrap 
http://www.w3.org/2001/04/xmlenc#kw-aes192 


Message Digest 


1. REQUIRED SHA1 (Use is DISCOURAGED; see below). 
http://www.w3.org/2000/09/xmldsig#sha1 

2. REQUIRED SHA256 
http://www.w3.org/2001/04/xmlenc#sha256 

3. OPTIONAL SHA384 
http://www.w3.org/2001/04/xmlenc#sha384 

4. OPTIONAL SHA512 
http://www.w3.org/2001/04/xmlenc#sha512 

5. OPTIONAL RIPEMD-160 
http://www.w3.org/2001/04/xmlenc#ripemd160 


Canonicalization 


1. OPTIONAL Canonical XML 1.0 (omit comments) 
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 

2. OPTIONAL Canonical XML 1.0 (with comments) 
http://www.w3.org/TR/2001/REC-xml-c1 4n-20010315#WithComments 

3. OPTIONAL Canonical XML 1.1 (omit comments) 
http://www.w3.org/2006/12/xml-c14n11 

4. OPTIONAL Canonical XML 1.1 (with comments) 
http://www.w3.org/2006/12/xml-c14n11#WithComments 

5. OPTIONAL Exclusive XML Canonicalization 1.0 (omit comments) 
http://www.w3.org/2001/10/xml-exc-c14n# 

6. OPTIONAL Exclusive XML Canonicalization 1.0 (with comments) 
http://www.w3.org/2001/10/xml-exc-c14n#WithComments 


Encoding 


1. REQUIRED base64 (*note) 
http://www.w3.org/2000/09/xmldsigitbase64 


Transforms 


1. REQUIRED base64 (*note) 
http://www.w3.org/2000/09/xmidsig#base64 


*note: The same URI is used to identify base64 both in "encoding" context (e.g. when used with the Encoding attribute of an EncryptedKey 
element, see section 3.1 The EncryptedType Element) as well as in "transform" context (when identifying a base64 transform for a 
CipherReference, see section 3.3.1 The CipherReference Element). 


5.2 Block Encryption Algorithms 


Block encryption algorithms are designed for encrypting and decrypting data in fixed size, multiple octet blocks. Their identifiers appear as 
the value of the Algorithm attributes of EncryptionMethod elements that are children of EncryptedData. 


Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks. 


Block encryption algorithms take, as implicit arguments, the data to be encrypted or decrypted, the keying material, and their direction of 
operation. For all of these algorithms specified below, an initialization vector (IV) is required that is encoded with the cipher text. For user 
specified block encryption algorithms, the IV, if any, could be specified as being with the cipher data, as an algorithm content element, or 
elsewhere. 


The IV is encoded with and before the cipher text for the algorithms below for ease of availability to the decryption code and to emphasize 
its association with the cipher text. Good cryptographic practice requires that a different IV be used for every encryption. 


5.2.1 Padding 


Since the data being encrypted is an arbitrary number of octets, it may not be a multiple of the block size. This is solved by padding the plain 
text up to the block size before encryption and unpadding after decryption. The padding algorithm is to calculate the smallest non-zero 
number of octets, say N, that must be suffixed to the plain text to bring it up to a multiple of the block size. We will assume the block size is B 
octets so N is in the range of 1 to B. Pad by suffixing the plain text with N-1 arbitrary pad bytes and a final byte whose value is N. On 
decryption, just take the last byte and, after sanity checking it, strip that many bytes from the end of the decrypted cipher text. 


Por ejemplo, supongamos un tamaño de bloque de 8 bytes y un texto sin formato de 0x616263. El texto sin formato acolchado estaría 


5.2.2 Triple DES 


Identificador: 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc 


NIST SP800-67 [ SP800-67 ] especifica tres operaciones FIPS 46-3 [ DES ] secuenciales. El cifrado XML TRIPLEDES consta de un cifrado 
DES, un descifrado DES y un cifrado DES utilizado en el modo Cipher Block Chaining (CBC) con 192 bits de clave y un vector de 
inicialización (IV) de 64 bits. De los bits clave, los primeros 64 bits se utilizan en la primera operación DES, los segundos 64 bits en la 
operación DES intermedia y los terceros 64 bits en la última operación DES. 


Nota: Cada uno de estos 64 bits de clave contiene 56 bits efectivos y 8 bits de paridad. Por tanto, sólo hay 168 bits operativos de los 192 
que se transportan para una clave TRIPLEDES. (Dependiendo del criterio utilizado para el análisis, se puede pensar que la fuerza efectiva de 
la clave es de 112 bits (debido a los ataques intermedios) o incluso menos). 


El texto cifrado resultante tiene el prefijo IV. Si se incluye en la salida XML, está codificado en base64. Un ejemplo de método de cifrado 
TRIPLEDES es el siguiente: 


EJEMPLO 23 


< Algoritmo del método de cifrado = "http: //ww.w3.org/2001/04/xmlencittripledes-cbc" /> 


Nota : Los algoritmos de cifrado de bloques CBC no deben utilizarse sin tener en cuenta posibles riesgos de seguridad graves . 


5.2.3 AES 


Identificador: 
http://www.w3.org/2001/04/xmlenc+taes128-cbc 
http://www.w3.org/2001/04/xmlenc+taes192-cbc 
http://www.w3.o0rg/2001/04/xmlenc+taes256-cbc 


[ AES ] se utiliza en el modo Cipher Block Chaining (CBC) con un vector de inicialización (IV) de 128 bits. El texto cifrado resultante tiene el 
prefijo IV. Si se incluye en la salida XML, está codificado en base64. Un ejemplo de método de cifrado AES es el siguiente: 


EJEMPLO 24 


< Algoritmo del método de cifrado = "http: //ww.w3.org/2001/04/xmlencitaes128-cbc" /> 


Nota : Los algoritmos de cifrado de bloques CBC no deben utilizarse sin tener en cuenta posibles riesgos de seguridad graves . 
5.2.4 AES-GCM 


Identificador: 
http://www.w3.org/2009/xmlenc11+taes128-gcm 
http://www.w3.org/2009/xmlenc11+taes192-gcm 
http://www.w3.org/2009/xmlenc11+taes256-gcm 


AES-GCM [ SP800-38D ] es un mecanismo de cifrado autenticado. Equivale a realizar estas dos operaciones en un solo paso: cifrado AES 
seguido de firma HMAC. 


AES-GCM is very attractive from a performance point of view because the cost of AES-GCM is similar to regular AES-CBC encryption, yet it 
achieves the same result as encryption and HMAC signing. Also AES-GCM can be pipelined so it is amenable to hardware acceleration. 


For the purposes of this specification, AES-GCM shall be used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). 
The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during 
encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified 
Authentication Tag, and fail if they don't match. For details on the implementation of AES-GCM, see [SP800-38D]. 


5.3 Stream Encryption Algorithms 


Simple stream encryption algorithms generate, based on the key, a stream of bytes which are XORed with the plain text data bytes to 
produce the cipher text on encryption and with the cipher text bytes to produce plain text on decryption. They are normally used for the 
encryption of data and are specified by the value of the Algorithm attribute of the EncryptionMethod child of an EncryptedData element. 


NOTE: It is critical that each simple stream encryption key (or key and initialization vector (IV) if an IV is also used) be used once only. If the 
same key (or key and IV) is ever used on two messages then, by XORing the two cipher texts, you can obtain the XOR of the two plain texts. 
This is usually very compromising. 


No specific stream encryption algorithms are specified herein but this section is included to provide general guidelines. 


Stream algorithms typically use the optional KeySize explicit parameter. In cases where the key size is not apparent from the algorithm URI 
or key source, as in the use of key agreement methods, this parameter sets the key size. If the size of the key to be used is apparent and 
disagrees with the KeySize parameter, an error MUST be returned. Implementation of any stream algorithms is optional. The schema for the 
KeySize parameter is as follows: 


Schema Definition: 


<simpleType name="KeySizeType"> 
<restriction base="integer"/> 
</simpleType> 


5.4 Key Derivation 


Key derivation is a well-established mechanism for generating new cryptographic key material from some existing, original ("master") key 
material and potentially other information. Derived keys are used for a variety of purposes including data encryption and message 
authentication. The reason for doing key derivation itself is typically a combination of a desire to expand a given, but limited, set of original 
key material and prudent security practices of limiting use (exposure) of such key material. Key separation (such as avoiding use of the 
same key material for multiple purposes) is an example of such practices. 


The key derivation process may be based on passphrases agreed upon or remembered by users, or it can be based on some shared 
"master" cryptographic keys (and be intended to reduce exposure of such master keys), etc. Derived keys themselves may be used in XML 
Signature and XML Encryption as any other keys; in particular, they may be used to compute message authentication codes (e.g. digital 
signatures using symmetric keys) or for encryption/decryption purposes. 


5.4.1 ConcatKDF 


Identifier: 
http://www.w3.org/2009/xmlenc11#ConcatKDF 


The ConcatKDF key derivation algorithm, defined in Section 5.8.1 of NIST SP 800-56A [SP800-56A] (and equivalent to the KDF3 function 
defined in ANSI X9.44-2007 [ANSI-X9-44-2007] when the contents of the Other Info parameter is structured as in NIST SP 800-56A), takes 
several parameters. These parameters are represented in the xenc11:ConcatKDFParamsType: 


Schema Definition: 
<!-- targetNamespace=8&#x27;http://ww.w3.org/2009/xmlenc1 1#8&#X27; --> 


<!-- use this element type as a child of xenc11:KeyDerivationMethod 
when used with ConcatKDF --> 
<element name="ConcatKDFParams" type="xenc11:ConcatKDFParamsType"/> 


<complexType name="ConcatKDFParamsType"> 
<sequence> 
<element ref="ds:DigestMethod"/> 
</sequence> 
<attribute name="AlgorithmID" type="hexBinary"/> 
<attribute name="PartyUInfo" type="hexBinary"/> 
<attribute name="PartyVInfo" type="hexBinary"/> 
<attribute name="SuppPubInfo" type="hexBinary"/> 
<attribute name="SuppPrivInfo" type="hexBinary"/> 
</complexType> 


The ds :DigestMethod element identifies the digest algorithm used by the KDF. Compliant implementations MUST support SHA-256 and SHA- 
1 (support for SHA-1 is present only for backwards-compatibility reasons). Support for SHA-384 and SHA-512 is OPTIONAL. 


The Algor ithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivinfo attributes are as defined in [SP800-56A]. Their presence is optional 
but AlgorithmID, PartyVInfo and PartyUInfo MUST be present for applications that need to comply with [SP800-56A]. Note: The PartyUInfo 
component shall include a nonce when ConcatKDF is used in conjunction with a static-static Diffie-Hellman (or static-static ECDH) key 
agreement scheme; see further [SP800-56A]. 


In [SP800-56A], AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivinfo attributes are all defined as arbitrary-length bitstrings, 
thus they may need to be padded in order to be encoded into hexBinary for XML Encryption. The following padding and encoding method 
MUST be used when encoding bitstring values for the A1gorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo: 


1. The bitstring is divided into octets using big-endian encoding. If the length of the bitstring is not a multiple of 8 then add padding bits 
(value 0) as necessary to the last octet to make it a multiple of 8. 


2. Prepend one octet to the octets string from step 1. This octet shall identify (in a big-endian representation) the number of padding bits 
added to the last octet in step 1. 


3. Encode the octet string resulting from step 2 as a hexBinary string. 


Example: the bitstring 11011, which is 5 bits long, gets 3 additional padding bits to become the bitstring 11011000 (or D8 in hex). This bitstring 
is then prepended with one octet identifying the number of padding bits to become the octet string (in hex) 03D3, which then finally is 
encoded as a hexBinary string value of "03D8". 


Note that as specified in [SP800-56A], these attributes shall be concatenated to form a bit string “OtherInfo” that is used with the key 
derivation function. The concatenation SHALL be done using the original, unpadded bit string values.” Applications MUST also verify that 
these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800- 
56. 


An example of an xenc11:DerivedKey element with this key derivation algorithm given below. In this example, the bitstring value of 
AlgorithmID is 00000000, the bitstring value of PartyUInfo is 11011 and the bitstring value of PartyVInfo is 11010: 
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<xenc11:DerivedKey xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:ds = "http://ww.w3.org/2000/09/xmldsigH" x 


NOTA 
Si bien se puede usar cualquier cadena de bits con ConcatKDF, se RECOMIENDA mantener los bytes alineados para una mayor 
interoperabilidad. 


5.4.2 PBKDF2 


Identificador: 
http://www.w3.org/2009/xmlenc11#pbkdf2 


El algoritmo de derivación de claves PBKDF2 y las definiciones de tipo ASN.1 para sus parámetros se definen en PKCS #5 v2.0 [ PKCS5 ]. 
Las definiciones del esquema XML para los parámetros se definen en [ PKCS5Amd1 ] y las mismas se pueden especificar encerrándolas 
dentro de un xenc11:PBKDF2-paramselemento secundario del xenc11:KeyDerivationMethodelemento. 


Definición del esquema : 


< nombre del elemento = "PBKDF2-params" tipo = "xenc11:PBKDF2ParameterType" /> 


<complexType nombre = "PBKDF2ParameterType" > <secuencia> <elemento nombre = "Salt" > <complexType> <elección> <elemento nombr 
<complexType nombre = "AlgorithmIdentifierType" > <secuencia> <elemento nombre = "Parámetros" tipo = "anyType" minOccurs = "0" 
<complexType nombre = "PRFAlgorithmIdentifierType" > <complexContent> <restricción base = "xenc11:AlgorithmIdentifierType" > < 


(Nota: se agregó una nueva linea al atributo Algoritmo para que quepa en esta página, pero no forma parte del URI). 


El PBKDF2-paramselemento y sus elementos secundarios tienen los mismos nombres y significados que los componentes correspondientes 
del PBKDF2-paramstipo ASN.1 en [PKCS5 ]. Tenga en cuenta que, en el caso de ConcatKDF y el KDF heredado de Diffie Hellman, keyLengthes 
un parámetro implícito y debe inferirse del contexto, pero en el caso de PBKDF2, el keyLengthelemento secundario debe especificarse, ya 
que se ha convertido en un parámetro obligatorio. consistente con PKCS5. Para PBKDF2, la longitud de la clave inferida debe coincidir con 
la longitud de la clave especificada; de lo contrario, se trata de una condición de error. 


Corresponde AlgorithmIdentifierTypeal AlgorithmIdentifiertipo de [ PKCS5] y lleva el identificador del algoritmo en el A1gorithmatributo. 
Los parámetros específicos del algoritmo, cuando corresponda, se pueden especificar utilizando el Parameterselemento. 


Se PRFAlgorithmIdentifierTypederiva de AlgorithmIdentifierTypey limita la elección de algoritmos a los contenidos en el conjunto 
PBKDF2-PRF definido en [ PKCS5 ]. Este tipo se utiliza para especificar una función pseudoaleatoria (PRF) para PBKDF2. Mientras que 
HMAC-SHA1 es el algoritmo PRF predeterminado en [ PKCS5 ], esta especificación RECOMIENDA EL USO DE HMAC-SHA256 (CONSULTE [ 
XMLDSIG-CORE1 ], [ HMAC ]). 


Un ejemplo de un xenc11:Derivedkeyelemento con este algoritmo de derivación de claves es: 
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<xenc11:DerivedKey 
xmlns:xsi="http://ww.w3.org/2001/XMLSchema- instance" 
xmlns:xenc="http://ww.w3.org/2001/04/xmlenc+t" 
xmlns:xenc11="http://ww.w3.org/2009/xmlenc11+4t"> 
<xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#pbkdf2"/> 
<xenc11:PBKDF2-params> 
<xenc11:Salt> 
<xenc11:Specified>Df3dRAhjGh8=</xenc11:Specified> 
</xenc11:Salt> 
<xenc11:IterationCount>2000</xenc11:IterationCount> 
<xenc11:KeyLength>16</xenc11:KeyLength> 
<xenc11:PRF Algorithm="http://ww.w3.org/2001/04/xmldsig-more#hmac-sha256"/> 
</xenc11:PBKDF2-params> 
</xenc11:KeyDerivationMethod> 
<xenc:ReferenceList> 
<xenc:DataReference URI="#ED"/> 
</xenc:ReferenceList> 
<xenc11:MasterKeyName>Our shared secret</xenc11:MasterKeyName> 
</xenc11:DerivedKey> 


5.5 Key Transport 


Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. Their identifiers 
appear as Algorithm attributes to EncryptionMethod elements that are children of EncryptedKey. EncryptedKey is in turn the child of a 


ds:KeyInfo element. The type of key being transported, that is to say the algorithm in which it is planned to use the transported key, is given 
by the Algorithm attribute of the EncryptionMethod child of the EncryptedData or EncryptedKey parent of this ds: KeyInfo element. 


(Key Transport algorithms may optionally be used to encrypt data in which case they appear directly as the Algorithm attribute of an 
EncryptionMethod child of an EncryptedData element. Because they use public key algorithms directly, Key Transport algorithms are not 
efficient for the transport of any amounts of data significantly larger than symmetric keys.) 


5.5.1 RSA Version 1.5 


Identifier: 
http://www.w3.org/2001/04/xmlenc#rsa-1_5 


The RSAES-PKCS1-v1_5 algorithm, specified in RFC 3447 [PKCS1], takes no explicit parameters. An example of an RSA Version 1.5 
EncryptionMethod element is: 
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<EncryptionMethod Algorithm="http: //ww.w3.org/2001/04/xmlenc#rsa-1_5" /> 


The CipherValue for such an encrypted key is the base64 [RFC2045] encoding of the octet string computed as per RFC 3447 [PKCS1], 
section 7.2.1: Encryption operation]. As specified in the EME-PKCS1-v1_5 function RFC 3447 [PKCS1], section 7.2.1, the value input to the 
key transport function is as follows: 
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CRYPT ( PAD ( KEY )) 


where the padding is of the following special form: 


EXAMPLE 29 
02 | PS* | 00 | key 


where "|" is concatenation, "02" and "00" are fixed octets of the corresponding hexadecimal value, PS is a string of strong pseudo-random 
octets [RANDOM] at least eight octets long, containing no zero octets, and long enough that the value of the quantity being CRYPTed is one 
octet shorter than the RSA modulus, and "key" is the key being transported. The key is 192 bits for TRIPLEDES and 128, 192, or 256 bits for 
AES. 


Implementations MUST support this key transport algorithm for transporting 192-bit TRIPLEDES keys. Support of this algorithm for 
transporting other keys is OPTIONAL. RSA-OAEP is RECOMMENDED for the transport of AES keys. 


The resulting base64 [RFC2045] string is the value of the child text node of the CipherData element, e.g. 
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<CipherData> 

<CipherValue>IWijxQjUrcxBYoCei4QxjWo9Kg8D3p9t1WoT4 
t0/gyTE96639InOFZFY2/rvP+/bMJO1EArmKZsR5VW3rwoPxw=</CipherValue> 
</CipherData> 


(Note: A newline has been added to the CipherValue to fit on this page, but is not part of value.) 


Note: Implementation of RSA v1.5 is NOT RECOMMENDED due to security risks associated with the algorithm. 
5.5.2 RSA-OAEP 


Identifier: 

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (including MGF1 with SHA1 mask generation function) 
Identifier: 

http://www.w3.org/2009/xmlenc11#rsa-oaep 


El algoritmo RSAES-OAEP-ENCRYPT, como se especifica en RFC 3447 [ PKCS1 ], tiene opciones que definen la función de resumen del 
mensaje y la función de generación de máscara, así como un PSourceAlgorithm parámetro opcional. Los valores predeterminados definidos 
en RFC 3447 son SHA1 para el resumen del mensaje y MGF1 with SHA1para la función de generación de máscara. Tanto las funciones de 
resumen de mensajes como de generación de máscaras se utilizan en la operación EME-OAEP-ENCODE como parte de RSAES-OAEP- 
ENCRYPT. 


El identificador http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p define la función de generación de máscara como el valor fijo de MGF1 
with SHA1. En este caso NO DEBE proporcionarse el xenc11:MGFelemento opcional del xenc : EncryptionMethodelemento . 


El identificador http://www.w3.org/2009/xmlenc11#rsa-oaep define la función de generación de máscara utilizando el xenc11:MGF elemento 
opcional del xenc:EncryptionMethodelemento. Si no está presente, MGF1 with SHA1se utilizará el valor predeterminado de. 


Los siguientes URI definen los distintos valores de URI de la función de generación de máscaras que se pueden utilizar. Estos corresponden 
a los identificadores de objetos definidos en RFC 4055 [ RFC4055 ]: 


MGF1 con SHA1: http://www.w3.org/2009/xmlenc11#mgf1sha1 

MGF1 con SHA224: http://www.w3.org/2009/xmlenc11#mgf1sha224 
MGF1 con SHA256: http://www.w3.org/2009/xmlenc11#mgf1sha256 
MGF1 con SHA384: http://www.w3.org/2009/xmlenc11#mgf1sha384 
MGF1 con SHA512: http://www.w3.org/2009/xmlenc11#mgf1sha512 


De lo contrario, los dos identificadores definen el mismo uso del algoritmo RSA-OAEP, como sigue. 


La función de resumen del mensaje DEBE especificarse utilizando el atributo Algoritmo del ds :DigestMethodelemento secundario del 
xenc:EncryptionMethodelemento. Si no se especifica, sHA1se utilizará el valor predeterminado de. 


PSourceAlgorithmEl valor del parámetro RSA-OAEP opcional PUEDE proporcionarse explícitamente colocando los octetos codificados en 
base64 en el xenc: OAEPparamselemento XML. 


La definición y descripción del esquema XML Encryption 1.0 para el EncryptionMethodelemento se encuentran en la sección 3.2 El elemento 
EncryptionMethod . A continuación se muestra la adición de XML Encryption 1.1 para el tipo MGF: 


Definición del esquema : 
< nombre del elemento = "MGF" tipo = "xenc11:MGFType" /> 


<complexType nombre = "MGFType" > <complexContent> <restricción base = "xenc11:AlgorithmIdentifierType" > <atributo nombre = " 


Un ejemplo de un elemento RSA-OAEP es: 


EJEMPLO 31 


< Algoritmo de método de cifrado = "http://ww.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" > <OAEPparams> 91Wu3Q== </OAEPparams> < 
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< Algoritmo de método de cifrado = "http://ww.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" > <OAEPparams> 91Wu3Q== </OAEPparams> < 


Otro ejemplo es: 
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< Algoritmo de método de cifrado = "http://ww.w3.org/2009/xmlenc11itrsa-oaep" > <OAEPparams> 91Wu3Q== </OAEPparams> <xenc11: 


La CipherValueclave cifrada RSA-OAEP es la codificación base64 [ RFC2045 ] de la cadena de octetos calculada según RFC 3447 [ PKCS1 l, 
sección 7.1.1: Operación de cifrado. Como se describe en la función EME-OAEP-ENCODE RFC 3447 [ PKCS1 ], sección 7.1.1, el valor 
ingresado a la función de transporte de claves se calcula usando la función de resumen de mensajes y la cadena especificada en los 
elementos DigestMethody OAEPparams y usando la función de generador de máscaras. especificado con el xenc11:MGFelemento o el valor 
predeterminado MGF1 with SHA1especificado en RFC 3447. La longitud de salida deseada para EME-OAEP-ENCODE es un byte más corto 
que el módulo RSA. 


El tamaño de la clave transportada es de 192 bits para TRIPLEDES y de 128, 192 o 256 bits para AES. Las implementaciones DEBEN 
implementar RSA-OAEP para el transporte de todos los tipos y tamaños de claves que son obligatorios para el cifrado simétrico. PUEDEN 
IMPLEMENTAR RSA-OAEP para el transporte de otras claves. 


5.6 Acuerdo clave 


A Key Agreement algorithm provides for the derivation of a shared secret key based on a shared secret computed from certain types of 
compatible public keys from both the sender and the recipient. Information from the originator to determine the secret is indicated by an 
optional OriginatorKeyInfo parameter child of an AgreementMethod element while that associated with the recipient is indicated by an 
optional RecipientKeyInfo. A shared key is derived from this shared secret by a method determined by the Key Agreement algorithm. 


Note: XML Encryption does not provide an online key agreement negotiation protocol. The AgreementMethod element can be used by the 
originator to identify the keys and computational procedure that were used to obtain a shared encryption key. The method used to obtain or 
select the keys or algorithm used for the agreement computation is beyond the scope of this specification. 


The AgreementMethod element appears as the content of a ds: KeyInfo since, like other ds: KeyInfo children, it yields a key. This ds: KeyInfo is 
in turn a child of an EncryptedData or EncryptedKey element. The Algorithm attribute and KeySize child of the EncryptionMethod element 
under this EncryptedData or EncryptedkKey element are implicit parameters to the key agreement computation. In cases where this 
EncryptionMethod algorithm URI is insufficient to determine the key length, a KeySize MUST have been included. 


Key derivation algorithms (with associated parameters) may be explicitly declared by using the xenc11:KeyDerivationMethod element. This 
element will then be placed at the extensibility point of the xenc : AgreementMethodType (see below). 


In addition, the sender may place a KA-Nonce element under AgreementMethod to assure that different keying material is generated even for 
repeated agreements using the same sender and recipient public keys. For example: 
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<EncryptedData> 
<EncryptionMethod Algorithm="Example:Block/Alg"> 
<KeySize>80</KeySize> 
</EncryptionMethod> 
<ds:KeyInfo xmlns:ds="http: //ww.w3.org/2000/09/xmldsig#"> 


<AgreementMethod Algorithm="example:Agreement/Algorithm"> 
<KA-Nonce>Zm9v</KA-Nonce> 
<xenc11:KeyDerivationMethod 
Algorithm="http://ww.w3.org/2009/xmlenc11HConcatKDF"> 
<xenc11:ConcatKDFParams 
AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
<ds:DigestMethod 
Algorithm="http://ww.w3.org/2001/04/xmlencitsha256"/> 
</xenc11:ConcatKDFParams> 
</xenc11:KeyDerivationMethod> 


<OriginatorKeyInfo> 
<ds:KeyValue>....</ds:KeyValue> 
</OriginatorKeyInfo> 
<RecipientKeyInfo> 
<ds:KeyValue>....</ds:KeyValue> 
</RecipientKeyInfo> 
</AgreementMethod> 
</ds:KeyInfo> 
<CipherData>. ..</CipherData> 
</EncryptedData> 


If the agreed key is being used to wrap a key, rather than data as above, then AgreementMethod would appear inside a ds: KeyInfo inside an 
EncryptedKey element. 


The Schema for AgreementMethod is as follows: 


Schema Definition: 
<element name="AgreementMethod" type="xenc:AgreementMethodType"/> 


<complexType name="AgreementMethodType" mixed="true"> 
<sequence> 
<element name="KA-Nonce" minOccurs="0" type="base64Binary"/> 
<!-- <element ref="ds:DigestMethod" minOccurs="0"/> --> 
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> 
<element name="OriginatorKeyInfo" minOccurs="0" 
type="ds:KeyInfoType"/> 
<element name="RecipientKeyInfo" minOccurs="0" 
type="ds:KeyInfoType"/> 
</sequence> 
<attribute name="Algorithm" type="anyURI" use="required"/> 
</complexType> 


5.6.1 Diffie-Hellman Key Values 


Identifier: 
http://www.w3.org/2001/04/xmlenc#DHKeyValue 


Diffie-Hellman keys can appear directly within KeyValue elements or be obtained by ds: RetrievalMethod fetches as well as appearing in 
certificates and the like. The above identifier can be used as the value of the Type attribute of Reference or ds:RetrievalMethod elements. 


As specified in [ESDH], a DH public key consists of up to six quantities, two large primes p and q, a "generator" g, the public key, and 
validation parameters "seed" and "pgenCounter". These relate as follows: The public key = ( g**x mod p ) where x is the corresponding 
private key; p = j*q + 1 where j >= 2. "seed" and "pgenCounter" are optional and can be used to determine if the Diffie-Hellman key has been 
generated in conformance with the algorithm specified in [ESDH]. Because the primes and generator can be safely shared over many DH 
keys, they may be known from the application environment and are optional. The schema for a DHKeyValue is as follows: 


Schema Definition: 
<element name="DHKeyValue" type="xenc : DHKeyValueType"/> 


<complexType name="DHKeyValueType"> 
<sequence> 
<sequence minOccurs="0"> 
<element name="P" type="ds:CryptoBinary"/> 
<element name="Q" type="ds:CryptoBinary"/> 
<element name="Generator"type="ds:CryptoBinary"/> 
</sequence> 
<element name="Public" type="ds:CryptoBinary"/> 
<sequence minOccurs="0"> 
<element name="seed" type="ds:CryptoBinary"/> 
<element name="pgenCounter" type="ds:CryptoBinary"/> 
</sequence> 
</sequence> 
</complexType> 


5.6.2 Diffie-Hellman Key Agreement 


The Diffie-Hellman (DH) key agreement protocol [ESDH] involves the derivation of shared secret information based on compatible DH keys 
from the sender and recipient. Two DH public keys are compatible if they have the same prime and generator. If, for the second one, Y = 
g**y mod p, then the two parties can calculate the shared secret ZZ = ( g**(x*y) mod p ) even though each knows only their own private 
key and the other party's public key. Leading zero bytes MUST be maintained in ZZ so it will be the same length, in bytes, as p. The size of p 
MUST be at least 512 bits and g at least 160 bits. There are numerous other complex security considerations in the selection of g, p, and a 
random x as described in [ESDH]. 


The Diffie-Hellman shared secret zz is used as the input to a KDF to produce a secret key. XML Signature 1.0 defined a specific KDF to be 
used with Diffie-Hellman; that KDF is now known as the "Legacy KDF" and is defined in Section 5.6.2.2. Use of Diffie-Hellman with explicit 
KDFs is described in Section 5.6.2.1. 


Implementation of Diffie-Hellman key agreement is OPTIONAL. However, if implemented, such implementations MUST support the Legacy Key 
Derivation Function and SHOULD support Diffie-Hellman with explicit Key Derivation Functions 


An example of a DH AgreementMethod element using the Legacy Key Derivation Function (Section 5.6.2.2) is as follows: 
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<AgreementMethod 
Algorithm="http://ww.w3.org/2001/04/xmlencitdh" 
ds:xmlns="http://ww.w3.org/2000/09/xmldsig#"> 
<KA-Nonce>Zm9v</KA-Nonce> 
<ds:DigestMethod Algorithm="http://ww.w3.org/2000/09/xmldsig#sha1"/> 
<OriginatorKeyInfo> 
<ds :X509Data> 
<ds:X509Certificate>...</ds:X509Certificate> 
</ds:X509Data> 
</OriginatorKeyInfo> 
<RecipientKeyInfo> 
<ds:KeyValue>...</ds:KeyValue> 
</RecipientKeyInfo> 
</AgreementMethod> 


5.6.2.1 Diffie-Hellman Key Agreement with Explicit Key Derivation Functions 


Identifier: 
http://www.w3.org/2009/xmlenc11#dh-es 


It is RECOMMENDED that the shared key material for a Diffie-Hellman key agreement be calculated from the Diffie-Hellman shared secret 
using a key derivation function (KDF) in accordance with Section 5.4. 


An example of a DH AgreementMethod element using an explicit key derivation function is as follows: 
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<xenc:AgreementMethod Algorithm="http: //ww.w3.org/2009/xmlenc11#dh-es"> 
<xenc11:KeyDerivationMethod Algorithm="http: //www.w3.org/2009/xmlenc11#ConcatKDF"> 
<xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
<ds:DigestMethod Algorithm="http://ww.w3.org/2001/04/xmlenc#sha256"/> 
</xenc11:ConcatKDFParams> 
</xenc11:KeyDerivationMethod> 
<xenc:OriginatorKeyInfo> 
<ds:X509Data> 
<ds:X509Certificate></-- X.509 Certificate here --></ds:X509Certificate> 
</ds :X509Data> 
</xenc: OriginatorKeyInfo> 
<xenc:RecipientKeyInfo> 
<ds :X509Data> 
<ds :X509SKI></ds : XSO9SKI> 
<!-- hint for the recipient's private key --> 
</ds:X509Data> 
</xenc: RecipientKeyInfo> 
</xenc: AgreementMethod> 


5.6.2.2 Diffie-Hellman Key Agreement with Legacy Key Derivation Function 


Identifier: 
http://www.w3.org/2001/04/xmlenc#dh 


XML Signature 1.0 defined a specific KDF for use with Diffie-Hellman key agreement. In order to guarantee interoperability, implementations 
that choose to implement Diffie-Hellman mMusT support the use of the Diffie-Hellman Legacy KDF defined in this section. 


Assume that the Diffie-Hellman shared secret is the octet sequence ZZ. The Diffie-Hellman Legacy KDF calculates the shared keying 
material as follows: 
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Keying Material = KM(1) | KM(2) | 


where "|" is byte stream concatenation and 
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KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg 
KA-Nonce | KeySize ) 


DigestAlg 
The message digest algorithm specified by the DigestMethod child of AgreementMethod. 
EncryptionAlg 
The URI of the encryption algorithm, including possible key wrap algorithms, in which the derived keying material is to be used 
("Example:Block/Alg" in the example above), not the URI of the agreement algorithm. This is the value of the Algorithm attribute of the 
EncryptionMethod child of the EncryptedData or EncryptedKey grandparent of AgreementMethod 
KA-Nonce 
The base64 decoding the content of the KA-Nonce child of AgreementMethod, if present. If the KA-Nonce element is absent, it is null. 
Counter 
A one byte counter starting at one and incrementing by one. It is expressed as two hex digits where letters A through F are in upper 
case. 
KeySize 
The size in bits of the key to be derived from the shared secret as the UTF-8 string for the corresponding decimal integer with only 
digits in the string and no leading zeros. For some algorithms the key size is inherent in the URI. For others, such as most stream 


ciphers, it must be explicitly provided. 


For example, the initial (km(1)) calculation for the EncryptionMethod of the Key Agreement example (section 5.5) would be as follows, where 
the binary one byte counter value of 1 is represented by the two character UTF-8 sequence 01, ZZ is the shared secret, and "foo" is the 
base64 decoding of "Zm9v". 
EXAMPLE 39 
SHA-1 ( ZZ01Example:Block/Algfoo80 ) 


Assuming that ZZ is 0xDEADBEEF, that would be 


EXAMPLE 40 
SHA-1( OxDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 ) 


whose value is 


EXAMPLE 41 
0x534C9B8C4ABDCB50038B42015A181711068B08C1 


Each application of DigestAlg for successive values of Counter will produce some additional number of bytes of keying material. From the 
concatenated string of one or more kI's, enough leading bytes are taken to meet the need for an actual key and the remainder discarded. 
For example, if DigestAlg is SHA-1 which produces 20 octets of hash, then for 128 bit AES the first 16 bytes from km(1) would be taken and 
the remaining 4 bytes discarded. For 256 bit AES, all of km(1) suffixed with the first 12 bytes of KM(2) would be taken and the remaining 8 
bytes of kM(2) discarded. 


5.6.3 Elliptic Curve Diffie-Hellman (ECDH) Key Values 


Identifier: 
http://www.w3.org/2009/xmidsig11#ECKeyValue 


ECDH has identical public key parameters as ECDSA and can be represented with the ECKeyValue element [XMLDSIG-CORE1]. Note that if 
the curve parameters are explicitly stated using the ECParameters element, then the Cofactor element musT be included. 


As with Diffie-Hellman keys, Elliptic Curve Key Values can appear directly within KeyValue elements or be obtained by ds:RetrievalMethod 


fetches as well as appearing in certificates and the like. The above identifier can be used as the value of the Type attribute of Reference or 
ds:RetrievalMethod elements. 


5.6.4 Elliptic Curve Diffie-Hellman (ECDH) Key Agreement (Ephemeral-Static Mode) 


Identifier: 
http://www.w3.org/2009/xmlenc11#ECDH-ES 


ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in [ECC- 
ALGS]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair 
for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters. 


Compliant implementations are REQUIRED to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 
186-3 [FIPS-186-3]. (This is the same curve that is REQUIRED in XML Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It 
is further RECOMMENDED that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in 
Sections D.2.4 and D.2.5 of FIPS 186-3, respectively. 


The shared key material is calculated from the Diffie-Hellman shared secret using a key derivation function (KDF). While applications may 
define other KDFs, compliant implementations MUST implement ConcatKDF (see section 5.4.1 ConcatKDF). An example of 
xenc:EncryptedData using the ECDH-ES key agreement algorithm with the ConcatKDF key derivation algorithm is as follows: 


EXAMPLE 42 


<xenc:EncryptedData 
xmlns:xsi="http://ww.w3.org/2001/XMLSchema-instance" 
xmlns:xenc="http://ww.w3.org/2001/04/xmlenc#" 
xmlns:ds="http://ww.w3.org/2000/09/xmldsig#" 
xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" 
xmlns:xenc11="http: //www.w3.org/2009/xmlenc11#" 
Type="http: //ww.w3.org/2001/04/xmlenc#"> 


<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" /> 
<!-- describes the encrypted AES content encryption key --> 
<ds : KeyInfo> 
<xenc:EncryptedKey> 
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/> 
<!-- describes the key encryption key --> 
<ds : KeyInfo> 
<xenc:AgreementMethod Algorithm="http: //www.w3.org/2009/xmlenc11#ECDH-ES"> 
<xenc11:KeyDerivationMethod Algorithm="http: //ww.w3.org/2009/xmlenc11#ConcatKDF"> 
<xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
<ds:DigestMethod Algorithm="http://ww.w3.org/2001/04/xmlencitsha256"/> 
</xenc11:ConcatKDFParams> 
</xenc11:KeyDerivationMethod> 
<xenc:OriginatorKeyInfo> 
<ds : KeyValue> 
<dsig11:ECKeyValue> 
<!-- ephemeral ECC public key of the originator --> 
</dsig11:ECKeyValue> 


</ds : KeyValue> 
</xenc:OriginatorKeyInfo> 
<xenc:RecipientKeyInfo> 
<ds:X509Data> 
<ds :X509SKI></ds : X509SKI> 
<!-- hint for the recipient's private key --> 
</ds:X509Data> 
</xenc:RecipientKeyInfo> 
</xenc:AgreementMethod> 
</ds:KeyInfo> 
<xenc: CipherData> 
<xenc:CipherValue></-- encrypted AES content encryption key --></xenc:CipherValue> 
</xenc: CipherData> 
</xenc: EncryptedKey> 
</ds:KeyInfo> 


<xenc: CipherData> 
<xenc: CipherValue> 
<!-- encrypted data --> 
</xenc: CipherValue> 
</xenc: CipherData> 


</xenc:EncryptedData> 


5.7 Symmetric Key Wrap 


Symmetric Key Wrap algorithms are shared secret key encryption algorithms especially specified for encrypting and decrypting symmetric 
keys. When wrapped keys are used, then an EncryptedKey element will appear as a child of a ds: KeyInfo element. This EncryptedKey element 
will have an EncryptionMethod child whose Algorithm attribute in turn identifies the key wrap algorithm. 


The algorithm for which the encrypted key is intended depends on the context of the ds : KeyInfo element: ds: KeyInfo can occur as a child of 
either an EncryptedData or EncryptedKey element; in both cases, ds: KeyInfo will have an EncryptionMethod sibling that identifies the 
algorithm. 


EXAMPLE 43 


<EncryptedData |EncryptedKey> 
<EncryptionMethod Algorithm="@algi"/> 
<ds : KeyInfo> 
<EncryptedKey> 
<EncryptionMethod Algorithm="@alg2"/> 
</EncryptedKey> 
</ds:KeyInfo> 
</EncryptedData |EncryptedKey> 


5.7.1 CMS Triple DES Key Wrap 


Identifiers: 
http://www.w3.org/2001/04/xmlenc#kw-tripledes 


XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys as described in [CMS-WRAP] and may optionally 
support TRIPLEDES wrapping of other keys. 


An example of a TRIPLEDES Key Wrap EncryptionMethod element is as follows: 


EXAMPLE 44 


<EncryptionMethod Algorithm="http: //ww.w3.org/2001/04/xmlenc#kw-tripledes" /> 


5.7.2 AES KeyWrap 


Identifiers: 
http://www.w3.org/2001/04/xmlenc#kw-aes128 
http://www.w3.org/2001/04/xmlenc#kw-aes192 
http://www.w3.org/2001/04/xmlenc#kw-aes256 


Implementation of AES key wrap is described in [AES-WRAP]. It provides for confidentiality and integrity. This algorithm is defined only for 
inputs which are a multiple of 64 bits. The information wrapped need not actually be a key. The algorithm is the same whatever the size of 
the AES key used in wrapping, called the key encrypting key or KEK. The implementation requirements are indicated below. 


128 bit AES Key Encrypting Key 
Implementation of wrapping 128 bit keys REQUIRED. 
Wrapping of other key sizes OPTIONAL. 

192 bit AES Key Encrypting Key 
All support OPTIONAL. 

256 bit AES Key Encrypting Key 
Implementation of wrapping 256 bit keys REQUIRED. 
Wrapping of other key sizes OPTIONAL. 


5.8 Message Digest 
Message digest algorithms can be used in AgreementMethod as part of the key derivation, within RSA-OAEP encryption as a hash function, 


and in connection with the HMAC message authentication code method [HMAC] as described in [KMLDSIG-CORE1].) Use of SHA-256 is 
strongly recommended over SHA-1 because recent advances in cryptanalysis (see e.g. [SHA-1-Analysis], [SHA-1-Collisions] ) have cast 


doubt on the long-term collision resistance of SHA-1. Therefore, SHA-1 support is REQUIRED in this specification only for backwards- 
compatibility reasons. 


5.8.1 SHA1 


Identifier: 
http://www.w3.org/2000/09/xmldsig+tshal 


The SHA-1 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-1 DigestMethod element is: 
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<DigestMethod Algorithm="http://ww.w3.org/2000/09/xmldsig#sha1" /> 


A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20- 
octet octet stream. For example, the DigestValue element for the message digest: 


EXAMPLE 46 
A9993E36 4706816A BA3E2571 7850C26C 9CDOD89D 
from Appendix A of the SHA-1 standard would be: 


EXAMPLE 47 
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue> 


5.8.2 SHA256 


Identifier: 
http://www.w3.org/2001/04/xmlenc#sha256 


The SHA-256 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-256 DigestMethod element is: 


EXAMPLE 48 


<DigestMethod Algorithm="http: //ww.w3.org/2001/04/xmlenc#sha256" /> 


A SHA-256 digest is a 256-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 32- 
octet octet stream. 


5.8.3 SHA384 


Identifier: 
http://www.w3.org/2001/04/xmlenc#sha384 


The SHA-384 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-384 DigestMethod element is: 


EXAMPLE 49 
<DigestMethod Algorithm="http://ww.w3.org/2001/04/xmlenc#sha384" /> 


A SHA-384 digest is a 384-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 48- 
octet octet stream. 


5.8.4 SHA512 


Identifier: 
http://www.w3.org/2001/04/xmlenc#sha512 


The SHA-512 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-512 DigestMethod element is: 


EXAMPLE 50 
<DigestMethod Algorithm="http://ww.w3.org/2001/04/xmlenc#sha512" /> 


A SHA-512 digest is a 512-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 64- 
octet octet stream. 


5.8.5 RIPEMD-160 


Identifier: 
http://www.w3.org/2001/04/xmlenc#ripemd160 


The RIPEMD-160 algorithm [RIPEMD-160] takes no explicit parameters. An example of an RIPEMD-160 DigestMethod element is: 


[ EXAMPLE 51 


j <DigestMethod Algorithm="http://ww.w3.org/2001/04/xmlencHtripemd160" /> 


A RIPEMD-160 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 
20-octet octet stream. 


5.9 Canonicalization 
A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML. 
5.9.1 Inclusive Canonicalization 
Identifiers: 
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
http://www.ws3.org/TR/2001/REC-xml-c14n-20010315#WithComments 


http://www.w3.org/2006/12/xml-c14n11 
http://www.w3.org/2006/12/xml-c14n11#WithComments 


Canonical XML [XML-C14N11] is a method of serializing XML which includes the in scope namespace and xml namespace attribute context 
from ancestors of the XML being serialized. 


If XML is to be encrypted and then later decrypted into a different environment and it is desired to preserve namespace prefix bindings and 
the value of attributes in the "xml" namespace of its original environment, then the canonical XML with comments version of the XML 
should be the serialization that is encrypted. 


5.9.2 Exclusive Canonicalization 
Identifiers: 


http://www.w3.org/2001/10/xml-exc-c14n# 
http://www.w3.org/2001/10/xml-exc-c1 4n#WithComments 


Exclusive XML Canonicalization [XML-EXC-C14N] serializes XML in such a way as to include to the minimum extent practical the 
namespace prefix binding and xml namespace attribute context inherited from ancestor elements. 


It is the recommended method where the outer context of a fragment which was signed and then encrypted may be changed. Otherwise the 
validation of the signature over the fragment may fail because the canonicalization by signature validation may include unnecessary 
namespaces into the fragment. 


6. Security Considerations 


6.1 Chosen-Ciphertext Attacks 


A number of chosen-ciphertext attacks against implementations of this specification have been published and demonstrated. They all 
involve the following elements: 


1. The attacker knows about the format of the cleartext. 

2. The attacker is able to submit substantial numbers of ciphertext messages. 

3. The attacker is able to send arbitrary ciphertext, based on previous results. 

4. The attacker is able to force the server to use the same key (secret key by CBC-based attacks and server's private key by PKCS#1.5 
attacks) for processing of the adapted ciphertext. 

5. The server attempting to decrypt the ciphertext in some way signals whether the decrypted text is well-formed or not. 


The attacker uses the knowledge of the format and the information about well-formedness to construct a series of ciphertext guesses 
which reveal the plaintext with much less work than brute force. Attacks of this type have been demonstrated against symmetric encryption 
using CBC mode [XMLENC-CBC-ATTACK][XMLENC-CBC-ATTACK-COUNTERMEASURES] and on PKCS#1 v1.5. Other future attacks can be 
expected whenever these conditions are met. 


6.1.1 Attacks against the encrypted data (<EncryptedData> part) 


Using the CBC-based chosen-ciphertext attacks, the attacker sends to the server an XML document with modified encrypted data in the 
symmetric part (<EncryptedData>). After a few requests, the attacker is able to get the whole cleartext without knowledge of the symmetric 
key. 


It would seem that these attacks can be countered by by disrupting any of the conditions, however in practice only preventing condition 3 
(sending arbitrary ciphertext) is fully effective. To counter condition 3, it is necessary for the decrypting system to require authenticated 
integrity protection over the ciphertext. However, unless the mechanism used is bound to the encryption key, there will no way to be sure 
that the signer is not attempting to recover the plaintext. The simplest and most efficient way to do this is to use an authenticating block 
mode, such as GCM. An alternative would be an HMAC based on the encryption key over the ciphertext, but it is less efficient and provides 
no advantages. 


Other countermeasures are not likely to be effective. Limiting the number of messages presented or the number of messages using the 
same key is not practical in large server farms. Attackers can spread their attempts over different servers and long or short periods of time, 
to foil attempts to detect attacks in progress or determine the location of the attacker. 


Signaling well-formedness can occur by emitting different messages for distinct security errors or by exhibiting timing differences. 
Implementations should avoid these practices, however that is not sufficient to prevent such attacks in an XML protocol environment, such 
as SOAP. Using a technique called encryption wrapping, the attacker can insert the ciphertext in some schema-legal part of the message. If 
the decryption code notices a format error, an error will be returned, but if not the message will be passed to the application which will 
ignore the bogus plaintext and ultimately respond with an application level success or failure message. 


6.1.2 Attacks against the encrypted key (Bleichenbacher's Million question attack on PKCS#1.5) 


The goal of the attacker applying the Bleichenbacher's attack is to get the symmetric secret key, which is encrypted in the <EncryptedkKey> 
part. Afterward, he would be able to decrypt the whole data carried in the <EncryptedData> part. 


The basic idea of this attack is to modify the data in the <EncryptedKey> part, send the document to the server, and observe if the modified 
ciphertext contains PKCS#1.5 conformant data. This can be done by: 


1. Observing fault messages of the server notifying directly that the request was not PKCS#1.5 conformant (this should not happen). 

2. Enlarging the data in the <EncryptedData> part and observing the timing differences between inclusion of PKCS-valid and PKCS-invalid 
keys: if the key is PKCS-valid, the session key is extracted, and the large data is decrypted. Otherwise, the session key cannot be 
extracted and the large data is not processed, which yields a timing difference. 

3. Making specific modifications of the <EncryptedData> part based on CBC and padding-properties. 


These problems are described in detail in RFC 3218 [RFC3218]. 


The most effective countermeasure against the timing attack (2) is to generate a random secret key every time when the decrypted data 
was not PKCS#1-conformant. This way, the attacker would not get any timing side-channel. 


Please note however that this is not a valid countermeasure against the specific modification of the <EncryptedData> described in part (3). 
The attacker could still use a few millions of requests to decrypt the encrypted symmetric key. Therefore, we recommend the usage of RSA- 
OAEP. RSA-OAEP also has a risk of a chosen ciphertext attack [OAEP-ATTACK] which can be mitigated in security library implementations. 


6.1.3 Backwards Compatibility Attacks 


Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP and AES-GCM can become insecure when the adversary can 
force the server to process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 v1.5 or AES-CBC [XMLENC-BACKWARDS- 
COMP]: 


1. The attacker may be able to break the security of an AES-GCM ciphertext if he is able to force the server to process the ciphertext with 
AES-CBC and the same symmetric key. 

2. The attacker may be able to decrypt an RSA-OAEP ciphertext if he is able to force the server to process the ciphertext with RSA- 
PKCS#1 v1.5 and the same asymmetric key. 

3. The attacker may be able to forge valid server signatures if the server decrypts RSA-PKCS#1 v1.5 ciphertexts and the signatures are 
computed with the same asymmetric key pair. 


Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend the following to implementers: 


1. Implementations SHOULD always use a different public key pair for data confidentiality and for data integrity functionality. 

2. Implementations using symmetric keys SHOULD NOT use the same key material for different algorithms, even if serving the same 
purpose. Key derivation based on a single key and the algorithm identifier can be used to accomplish this, for example. 

3. Implementations that plan to use the same symmetric key for both confidentiality and integrity functions SHOULD use it as the basis 
for a key derivation producing different keys for those functions. 

4. Implementations SHOULD restrict algorithm usage to algorithms known to be secure in the face of chosen-ciphertext attacks (RSA- 
OAEP, AES-GCM). In that case, documents containing RSA-PKCS#1 v1.5 [XMLENC-PKCS15-ATTACK] and AES-CBC [XMLENC-CBC- 
ATTACK] ciphertexts SHOULD be rejected without decryption. 


6.2 Relationship to XML Digital Signatures 


The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature 
verification difficult. In particular, when verifying a signature one must know whether the signature was computed over the encrypted or 
unencrypted form of elements. 


A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a 
common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may 
allow plaintext guessing attacks. This vulnerability can be mitigated by using secure hashes and the nonces in the text being processed. 


In accordance with the requirements document [XML-ENCRYPTION-REQ] the interaction of encryption and signing is an application issue 
and out of scope of the specification. However, we make the following recommendations: 


1. When data is encrypted, any digest or signature over that data should be encrypted. This satisfies the first issue in that only those 
signatures that can be seen can be validated. It also addresses the possibility of a plaintext guessing vulnerability, though it may not 
be possible to identify (or even know of) all the signatures over a given piece of data. 


2. Employ the "decrypt-except" signature transform [XMLENC-DECRYPT]. It works as follows: during signature transform processing, if 
you encounter a decrypt transform, decrypt all encrypted content in the document except for those excepted by an enumerated set of 
references. 


Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, 
applications should discourage user misapprehension by communicating clearly which information has integrity, or is authenticated, 
confidential, or non-repudiable when multiple processes (e.g., signature and encryption) and algorithms (e.g., symmetric and asymmetric) 
are used: 


1. When an encrypted envelope contains a signature, the signature does not necessarily protect the authenticity or integrity of the 
ciphertext [Davis]. 


2. While the signature secures plaintext it only covers that which is signed, recipients of encrypted messages must not infer integrity or 
authenticity of other unsigned information (e.g., headers) within the encrypted envelope, see [XMLDSIG-CORE1], section 8.1.1 Only 
What is Signed is Secure]. 


6.3 Information Revealed 
Where a symmetric key is shared amongst multiple recipients, that symmetric key should only be used for the data intended for all 


recipients; even if one recipient is not directed to information intended (exclusively) for another in the same symmetric key, the information 
might be discovered and decrypted. 


Additionally, application designers should be careful not to reveal any information in parameters or algorithm identifiers (e.g., information in 
a URI) that weakens the encryption. 


6.4 Nonce and IV (Initialization Value or Vector) 


An undesirable characteristic of many encryption algorithms and/or their modes is that the same plaintext when encrypted with the same 
key has the same resulting ciphertext. While this is unsurprising, it invites various attacks which are mitigated by including an arbitrary and 
non-repeating (under a given key) data with the plaintext prior to encryption. In encryption chaining modes this data is the first to be 
encrypted and is consequently called the IV (initialization value or vector). 


Different algorithms and modes have further requirements on the characteristic of this information (e.g., randomness and secrecy) that 
affect the features (e.g., confidentiality and integrity) and their resistance to attack. 


Given that XML data is redundant (e.g., Unicode encodings and repeated tags ) and that attackers may know the data's structure (e.g., DTDs 
and schemas) encryption algorithms must be carefully implemented and used in this regard. 


For the Cipher Block Chaining (CBC) mode used by this specification, the IV must not be reused for any key and should be random, but it 
need not be secret. Additionally, under this mode an adversary modifying the IV can make a known change in the plain text after decryption. 
This attack can be avoided by securing the integrity of the plain text data, for example by signing it. 


Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks. 


For the Galois/Counter Mode (GCM) used by this specification, the IV must not be reused for any key and should be random, but it need not 
be secret. 


6.5 Denial of Service 


This specification permits recursive processing. For example, the following scenario is possible: EncryptedKey A requires EncryptedKey B to 
be decrypted, which itself requires EncryptedKey A! Or, an attacker might submit an EncryptedData for decryption that references network 
resources that are very large or continually redirected. Consequently, implementations should be able to restrict arbitrary recursion and the 
total amount of processing and networking resources a request can consume. 


6.6 Unsafe Content 


XML Encryption can be used to obscure, via encryption, content that applications (e.g., firewalls, virus detectors, etc.) consider unsafe (e.g., 
executable code, viruses, etc.). Consequently, such applications must consider encrypted content to be as unsafe as the unsafest content 
transported in its application context. Consequently, such applications may choose to (1) disallow such content, (2) require access to the 
decrypted form for inspection, or (3) ensure that arbitrary content can be safely processed by receiving applications. 


6.7 Error Messages 


Implementations SHOULD NOT provide detailed error responses related to security algorithm processing. Error messages should be limited to 
a generic error message to avoid providing information to a potential attacker related to the specifics of the algorithm implementation. For 
example, if an error occurs in decryption processing the error response should be a generic message providing no specifics on the details of 
the processing error. 


6.8 Timing Attacks 


It has been known for some time that it is feasible for an attacker to recover keys or cleartext by repeatedly sending chosen ciphertext and 
measuring the time required to process different requests with different types of errors. It has been demonstrated that attacks of this type 
are practical even when communicating over large and busy networks, especially if the receiver is willing to process large numbers of 
ciphertext blocks. 


Implementers SHOULD ensure that distinct errors detected during security algorithm processing do not consume systematically different 
amounts of processing time from each other. Implementers SHOULD consult the technical literature for more details on specific attacks and 
recommended countermeasures. 


Deployments SHOULD treat as suspect inputs when a large number of security algorithm processing errors are detected within a short period 
of time, especially in messages from the same origin. 


6.9 CBC Block Encryption Vulnerability 


Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks. 


7. Conformance 


An implementation is conformant to this specification if it successfully generates syntax according to the schema definitions and satisfies 
all MUST/REQUIRED/SHALL requirements, including algorithm support and processing. Processing requirements are specified over the roles of 
decryptor, encryptor, and their calling application. 


8. XML Encryption Media Type 


8.1 Introduction 


XML Encryption Syntax and Processing (XMLENC-CORE1, this document) specifies a process for encrypting data and representing the 
result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of 
encrypting data is an XML Encryption element which contains or references the cipher data. 


The application/xenc+xml media type allows XML Encryption applications to identify encrypted documents. Additionally it allows 
applications cognizant of this media-type (even if they are not XML Encryption implementations) to note that the media type of the 
decrypted (original) object might be a type other than XML. 


8.2 application/xenc+xml Registration 


This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG] 
Type name: application 

Subtype name: xenc+xml 

Required parameters: none 

Optional parameters: charset 


The allowable and recommended values for, and interpretation of the charset parameter are identical to those given for 
'application/xml' in section 3.2 of RFC 3023 [XML-MTI. 


Encoding considerations: 
The encoding considerations are identical to those given for 'application/xml' in section 3.2 of RFC 3023 [XML-MT]. 
Security considerations: 


See the (XMLENC-CORE1, this document) Security Considerations section. 


Interoperability considerations: none 
Published specification: (XMLENC-CORE1, this document) 
Applications which use this media type: 
XML Encryption is device-, platform-, and vendor-neutral and is supported by a range of Web applications. 
Additional Information: 
Magic number(s): none 


Although no byte sequences can be counted on to consistently identify XML Encryption documents, there will be XML 
documents in which the root element's QName's LocalPart is 'EncryptedData' or 'EncryptedKey' with an associated 
namespace name of ‘http://www.w3.org/2001/04/xmlenc#'. The application/xenc+xml type name MUST only be used 
for data objects in which the root element is from the XML Encryption namespace. XML documents which contain 
these element types in places other than the root element can be described using facilities such as [KMLSCHEMA-1], 
[XMLSCHEMA-2]. 


File extension(s): .xml 
Macintosh File Type Code(s): "TEXT" 
Person & email address to contact for further information: 
World Wide Web Consortium <web-human at w3.org> 
Intended usage: COMMON 


Author/Change controller: 


specification. 
9. Schema 


9.1 XSD Schema 


XML Encryption Core Schema Instance 

xenc-schema.xsd 
XML Encryption 1.1 Schema Instance 

xenc-schema11.xsd 

This schema document defines the additional material defined in XML Encryption 1.1. 
Example (non-normative) 

enc-example.xml (not cryptographically valid but exercises much of the schema) 


9.2 RNG Schema 


This section is non-normative. 


Non-normative RELAX NG schema [RELAXNG-SCHEMA] information is available in a separate document [XMLSEC-RELAXNG]. 
A. Reserved Algorithm Identifiers 


This informative section outlines the definition and reserves identifiers for algorithms that have no requirements for implementation and 
have not been tested for interoperability. 


A.1 AES KeyWrap with Padding 


This section is non-normative. 


Identifiers: 
http://www.w3.org/2009/xmlenc11#kw-aes-128-pad 
http://www.w3.org/2009/xmlenc11#kw-aes-192-pad 
http://www.w3.org/2009/xmlenc11#kw-aes-256-pad 


These identifiers are reserved for symmetric key wrapping using the AES key wrap with padding algorithm with a 128, 192, and 256 bit AES 
key encrypting key, respectively. Implementation of AES key wrap with padding is defined in [AES-WRAP-PAD]. The algorithm is defined for 
inputs between 9 and 2132 octets. Unlike the unpadded AES Key Wrap algorithm, the input length is not constrained to multiples of 64 bits 
(8 octets). 


Note that the wrapped key will be distinct from the one generated by the unpadded AES Key Wrap algorithm, even if the input length is a 
multiple of 64 bits. 
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